barmic a écrit 10455 commentaires

Et surtout ça n'empêche toujours pas la manière "traditionnelle" de fonctionner, ce qui conjugué à la façon dont fonctionnent par défaut les droits d'administration sur un ordinateur personnel équipé de Windows, le fameux dégoupillé de grenade, reste un très gros problème.

Si j'ai bien compris tu peut n'autoriser que les programmes signer.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Et là il se passe parfois des choses étranges qui font que la seule solution à ma portée est de réinstaller.

Quelqu'un a essayé les snapshot avant mise à jour ? Si tu utilise btrfs ou llvm (probablement aussi avec zfs), il y a moyen de créer une snapshot et d'ajouter une entrée dans le bootloader vers cette snapshot avant d'effectuer les mises à jour, ça devrait pourvoir résoudre un paquet de problème potentiel.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je trouve pas le gain de ce genre de choses démesuré. L'intérêt du pipe sur les appels de méthode chainé c'est le parallélisme. Pour le reste c'est plus du sucre syntaxique.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En quelques années, l'image des organismes de recherche, et en particulier du CNRS, se sont dégradées très significativement, et l'image du chercheur fonctionnaire, même si elle existait probablement au sein des milieux d'ultra-droite avant ça, s'est complètement banalisée au sein du grand public.

Je ne peux pas parler de ce qui se passe au sein des administrations, mais quand je vois ça : https://www.youtube.com/watch?v=sd1aqOfNaPs

Je me dis que l'image du chercheur est écorné depuis au moins les années 90 (pour rappel ce n'est pas la seule des nuls sur le thème). Je ne pense pas qu'on puisse parler ici d'ultra-droite.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

L'intérêt de PowerShell est vraiment dans le runtime .Net, c'est ce qui permet de construire des bouts avec les différents langages de la plateforme .Net tout en gardant les concepts objets.

Mais j'ai l'impression que PowerShell a du mal à décoller. Les admin/dev windows ne sont pas très enclins à s'y mettre et je ne sais pas si les gros logiciels MS ont une API PowerShell intéressantes (est-il envisageable de manipuler word via PowerShell par exemple ?).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça fait des années que je dis à tout le monde de ne rien installer si ça ne vient pas directement du site de l’éditeur du logiciel

Ça ne change rien. Il y a pleins d'éditeurs qui ajoutent des adware dans leur programmes.

En dehors du software center / synaptic ils ne savent pas installer quoi que ce soit.

C'est pas aussi le cas de Windows maintenant ? (on doit pouvoir retrouver des gros troll là dessus dans les journaux)
Les sites tel que clubic ou télécharger.com, voulaient faire office de dépôt, comme pour fdroid, au lieu de devoir faire confiance à chaque éditeur tu place ta confiance dans l'un ou l'autre, c'est plus simple. Mais je crois qu'ils n'ont jamais étaient digne de confiance.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En effet j'ai écris l'exemple un peu vite. Ça montre que ça reste casse gueule.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Locale pour UTC, il faut l'indiquer explicitement. Tu peut aller voir info date pour tous les détails.

Perso, je fais tous mes scripts en Python dès qu'il y a des dates (j'ai alors des objets datetime qui ont un fuseau horaire)

Ça tombe bien la commande date gère les fuseaux horaires.

Pour de gros besoin de date oui le shell n'est pas une bonne idée, de même pour les mathématiques, pour des choses simples, il n'y a pas de raison de tout réécrire pour si peu.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est vrai que ce n'est pas dit explicitement, mais c'est également une conséquence de ton interprétation "forte".
L'interprétation "forte" est: peu importe la blague, si un raciste rit, je ne ris pas. Donc, je ne ris jamais à aucune blague hilarante.
L'interprétation "faible" est: si un raciste rit, je ne ris pas. Donc, si c'est une blague raciste, la probabilité qu'un raciste rit est bien plus grande, donc, forcément, je ne ris pas aux blagues racistes (mais je ris aux autres vu que je ne sais pas si le raciste rit ou pas).

Alors là AMHA tu t'éloigne. Il ne parle pas du fait que les racistes (ou autre) rient ou pas. Au contraire, Le Pen rit beaucoup à la tirade de Desproges. Il dit la présence d'un terroriste ne me fait pas rire. L'ambiance que cela crée l'empêche de rire, il ne leur refuse pas le droit de rire ou de faire des blagues.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

PowerShell est probablement bien plus intéressant à utiliser.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Oui l'exemple de la libc n'est peut être pas le meilleur, mais si déjà t'évite les bugs classiques comme les mois de 28 à 31 jours par exemple c'est déjà pas mal.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Les dates sont une plaie en informatique. C'est vraiment très compliqué à gérer (entre les mois de 30 à 31 jours, sauf un qui fait 28 jours sauf tout les 4 ans, les secondes intercalaires qui peuvent être ajoutées ou supprimée de temps en temps, le changement d'heure…) et on trouve régulièrement des bug dans des logiciels pourtant éprouvés (la libc par exemple).

Mon conseil, ne gérer pas les dates vous même (en shell comme ailleurs). Laissez-ça à des API qui font ça très bien. En shell cette API c'est date (c'est un standard POSIX utilisable avec n'importe quel shell).

Son usage est assez simple (mais ça ne dispense pas de lire le man), l'idée c'est de convertir toutes les dates en entier (le nombre de secondes depuis epoch) puis de comparer ces entiers entre eux, puis de les convertir dans le format que l'on souhaite.

Par exemple si je souhaite dans mon script savoir si nous sommes après ou avant le 6 octobre 2014 je vais faire ça ainsi :

limit=$(date '+%s' -d '06/10/2014')
now=$(date '+%s')
if [ "${limit}" -lt "${now}" ] ; then
    echo "On a passé la date car $(date '+%d/%m/%y' -d "@$now") est plus grand que $(date '+%d/%m/%y' -d "@$limit")"
fi

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Autre chose coté performance, il vaut mieux ne pas trop croire et plutôt tester. J'ai eu de jolies déconvenues avec des script zsh dans les quels j'utilisais zargs (un outils pour utiliser un équivalent à xargs avec les globbings étendus) qui est assez peu efficace contrairement à ce que j'espérais.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

La gestion de la portabilité est un sujet assez épineux pour du shell. On parle souvent de se contenter de POSIX, il arrive que ce soit assez contraignant pour un intérêt limité.

Lorsque le code est distribué à l'ensemble de la planète, c'est normal de chercher la plus grande portabilité possible (et donc de choisir POSIX), mais dans bien d'autres cas ce n'est pas aussi clair :

• la portabilité d'un script est égale à la portabilité du programme le moins portable utilisé par ce script. Par exemple si on crée un script qui va utiliser apt-xapian (et dont c'est la raison d'être), il est inutile de chercher à ce que le script fonctionne sur Solaris, MacOS et git bash pour windows
• des fois (souvent ?) on a une plateforme cible, si on la connaît je ne vois personnellement pas de problème à la cibler plus particulièrement

Une autre approche de la portabilité peut être d'utiliser le moins de programmes possible. On peut par exemple créer un script zsh qui n'utilisera jamais le moindre outil GNU. Ça peut simplifier les dépendances (on ne dépend plus que de zsh) tout en ayant des fonctionnalités plus pratiques performantes.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Il faut aussi rappeler que s'il s'agit de logging la commande logger est faite pour ça.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Il m'arrive régulièrement de faire des scripts awk uniquement (avec le shbang #!/usr/bin/awk -f). J'avais notamment réécris en moins de 10 lignes un programme java d'un collègue qui analysait des logs ssh…

Moi je trouve assez amusant la manière de programmer en awk qui fait penser à de la programmation évènementielle ou un parseur SAX.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Mais je n'ai pas de recette toute faites pour dire ça c'est mieux en shell, tel autre en python.

Il y a des cas simples et clairement en faveur de l'un des deux. Si tu lance des programmes externes le shell est ton amis, si tu manipule beaucoup le système de fichier le shell est ton amis, si tu fais pas mal de calcul le shell est ton pire ennemis,…

Pour le reste ça dépend, des connaissances de celui qui développe, de la plateforme cible, etc

Personnellement, il faut arriver à un gros niveau de complexité pour que je quitte le shell. Mais je n'hésite pas à prendre perl comme un awk amélioré (sauf si je fais trop d'aller-retour entre le shell et perl).

Souvent le shell est mal maitrisé et t'a l'air d'un gourou dès que tu sort quelque chose d'un peu propre (et je ne parle pas d'awk…).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pas surprenant, je l'ai pas mis plus haut mais celui qui met un eval dans un script shell, doit mettre 15 lignes pour expliquer pourquoi il est obligé de faire ça.

Est-ce que par hasard tu connais des outils qui vont un pas plus loin et font du parallélisme distribué? Par exemple qui récupère une liste de comptes SSH et lance des programmes sur l'hôte distant?

Comme ça, non. Tu peux jouer un peu avec fabric, mais on quitte le monde du shell. Perso je pencherais plus pour faire quelque chose à coup de netcat/socat, mais ça doit demander pas mal de boilerplate. Pour arriver à quelque chose.

Bien sûr tu peut aussi simplement faire des ssh alias cmd¹ qui marche bien et qui te permet de récupérer le résultat.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai inversé les 2 prénoms… (désolé Guillaume si tu passe par là, je vais aller me fouetter)

Claude Allègre a pendant longtemps était plus polémiste que chercheur (par exemple au sujet du réchauffement climatique) ce qui n'aide pas à donner une image travailleur aux chercheur.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Le shell (quelque soit le shell) n'est pas performant, c'est mou que ça en peu plus (même dash) par conception. Pourtant on peut faire des programmes très performants en shell !

1. Les parties critiques peuvent être écris dans des langages différents (que ce soit du C ou un autre langage de script)
2. on peut très très très facilement faire du parallélisme poussé.

Il y a 2 grandes familles de parallélisme en shell qui sont très simples à faire.

Les pipelines, tout le monde les connais on les as tous déjà vu. Il y a des exemples plus hauts de programmes l'utilisant. On découpe un traitement en plusieurs étapes et chaque processus s'occupe d'une partie de ce traitement. On peut voir ça comme une programmation fonctionnelle. Chaque bout de programme est un filtre et a une entrée bien définie et une sortie bien définie (par exemple son entrée c'est des noms de fichiers et ça sortie c'est une sommes de contrôle un espace puis le nom du fichier).

Le parallélisme à la xargs (je connais pas le nom du paradigme), là il s'agit d'exécuter le traitement pleins de fois en parallèle. Il faut savoir qu'il n'y a pas que xargspour faire ça. find le fait aussi très bien avec le terminateur + à la place de ; en fin de commande. Il y a aussi gnu parallel, mais il est rarement installé.

L'énorme avantage de ces modes c'est qu'on ne lance pas des milliers de processus (notamment avec les pipes) ce qui est contre productif.

Si j'ai des conseils à donner sur les performances en shell, je conseil de regarder en priorité 3 choses :

• le nombre de fork, lancer pleins de fois le même programme c'est très lourd, il faut généralement voir pour lui donner toutes les données d'un coup ou voir pour le lancer en arrière plan et pouvoir lui fournir les données au fur et à mesure
• regarder les accès disque : utiliser des fichiers pour stocker des données interne au programme limite les performance (mais c'est des fois nécessaires vu que les pipes sont limités à 4Kio de données) et ajoute des la complexité (il ne faut pas de collision, il faut bien supprimer les fichiers à la fin du programme)
• quand on utilise les pipe éviter comme la peste les traitement au milieu des pipelines qui nécessitent l'ensemble des données. Par exemple un sort va totalement détruire les performance des pipes parce qu'il va attendre d'avoir toutes les données avant de pouvoir commencer sont travail

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Personnellement je ne les connais pas toutes mais il est intéressant souvent de travailler avec un langage qui ferra tout le boulot. Notamment awk est vraiment puissant et il est généralement inutile d'utiliser grep ou sed devant ou derrière un awk ce dernier faisant très bien le boulot.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pour la construction de la ligne de commande, il faut aussi parler de l'utilisation de -- pour déterminer la fin des options, on ne devrait jamais voir :

cp "$fichier1" "$fichier2"

mais plutôt

cp -- "$fichier1" "$fichier2"

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ceci dit, la théorie et les règles, c'est bien. Mais écrire des scripts SHELL qui tournent aussi bien sous *NIX que Mac OS, par exemple, ça rend les règles plus difficiles à suivre. Surtout en raison des différences entre les outils, genre sed et tar, pour ne citer qu'eux.

Pas tant que ça, les extensions GNU sont surtout utiles pour des usages interactifs ou sont assez peu connu.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Euh… D'où ça sort que maintenant les gens n'aiment pas les chercheurs ? L'image du chercheur feignant ça existe au moins depuis les années 90 (avec entre autre les polémiques autour de Guillaume Allègre), qu'est-ce qui vous fait dire qu'aujourd'hui c'est pire ? Au contraire l'émergence depuis 10 ans le fait que les geeks soient devenu à la mode, que le monde deviens hyper-connecté a tendance à rendre les gens plus sensible à la recherche scientifiques et aux sciences en générale (sans pour autant suivre des études scientifiques). Il n'y a qu'à voir qu'aujourd'hui on fait des séries dessus, rien de tel pour rendre ces travaux moins opaque et arrêter de faire croire aux gens que les chercheurs sont enfermés dans leurs labos.

Pour préciser les choses (parce que certains ne comprennent pas le sens de cette citation), le sens de la citation de Desproges est: on peut rigoler d'une blague sur les juifs entre potes, même si l'un d'eux est juif (et s'il le prend mal, tant pis pour lui), mais quand Lepen est parmi nous, la blague sur les juifs ne fait plus rire (car on sait que Lepen ne va pas rire de l'absurdité de la blague, mais parce que "c'est drôle parce que c'est vrai", et que la blague sert ici à valider le racisme).

Je ne crois pas du tout que c'était les propos de Desproges. Je ne vois pas dans sa plaidoirie de lien entre le sujet de l'humour et les personnes avec qui il rit (ou pas). AMHA, pour lui, rire avec monsieur Le Pen lui est juste impossible, même s'il s'agit d'une blague carambar.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Remplacer "Linux" par "GNU/Linux" dans certains fichiers, etc. ;

Là je vois pas à quoi ça sert. Ou alors c'est un moyen subtil de relancer le troll sur Linux vs GNU/Linux.

Il a prévenu :

D’abord, je précise que pour moi la raison doit être d’ordre éthique, …

Perso j'ai tendance à être d'accord avec Linus Torvald sur ce point :

Chaque fois que vous l’utilisez [l'éthique] dans un argument pour dire pourquoi quelqu’un d’autre devrait faire un truc, alors vous n’êtes plus éthique. Vous devenez juste une tête de con moralisatrice.

Linus Torvalds : l’interview anniversaire des 20 ans du noyau

Mais bon chacun son point de vu.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)