Une alternative : vim qui propose les mêmes choses sauf que pour moi c’est un éditeur et non pas un outil de visualisation.
Ça se discute : la commande view (fournie dans le paquet vim) est un alias de vim -R qui ouvre le fichier en lecture seule, empêchant les modifications mais permettant navigation, coloration syntaxique et autres friandises de vim.
L’avantage de pass n’est pas tant de stocker ses mots de passes avec git, mais surtout d’utiliser gpg pour les chiffrer. Ce qui permet d’avoir toute l’intégration qui va avec (clefs multiples, jetons de sécurité).
On va dire que c’est l’outil qui impose le moins de structure dans l’organisation des mdp, ce qui le rend à la fois ultra configurable, mais également réservé à un public sachant ce qu’il fait
Je n’ai pas d’expérience dans le domaine mais je pense que l’important est d’utiliser les outils qui nous conviennent. Si l’outil est complexe le temps d’apprentissage est plus long pour parvenir à une maîtrise. Il semble que cela soit fastidieux pour l’auteur de passer en revue du texte. À mon avis, c’est parce que son approche n’est pas efficace : lire du texte en séquence (e.g. Emacs Rocks! Episode 12: Working with HTML). Évidemment, il y a des avantages et des inconvénients.
C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine.
Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.
J’ai rectifié pour la partie branch main, je te remercie :)
J’ai un avis mitigé sur cet article.
Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…
Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.
Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).
Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)
PS: Une petite imprécision quand même, main n’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).
Mes remarques peuvent paraître pointilleuses mais c’est important pour la compréhension.
Tous les fichiers de configuration de mon système dans le répertoire /etc sont protégés en écriture pour un utilisateur courant.
find /etc -type f -writable
La commande cat combinée avec grep est fautive sans que l’on comprenne vraiment pourquoi. On pourrait penser que c’est plutôt équivalent à cat /etc/passwd ; grep bash /etc/passwd. L’utilisateur souhaite afficher le contenu du fichier, s’aperçoit que cat n’est pas adapté et réduit donc à l’essentiel ce qui est affiché grâce à grep. Néanmoins, il faut savoir que des commandes fonctionnent directement avec des fichiers et dans des pipes. Cela est éventuellement plus difficile dans la manière d’exposer mais le propos n’est pas forcément plus compliqué (quoique plus fastidieux).
On comprend que grep "PS1" /etc/* est incorrect puisque le motif du nom de fichier donne accès à des fichiers quelconques (caractère de substitution étoile) dans un répertoire rempli de fichiers. Peu importe que la recherche soit poursuivie dans les sous-répertoires mais cela paraît plus logique et surtout correct.
/usr/bin est accessible en lecture à tout le monde.
On s’en fiche des processus lancés par -exec. C’est un cours d’introduction au shell, pas un exposé sur l’optimisation à outrance des commandes du shell.
L’exemple avec le “useless use of cat” est avant tout pédagogique. D’ailleurs il aurait suffi de lire la phrase juste après pour s’en rendre compte. C’est expliqué. Suffit de lire l’article.
Ben non, la recherche n’est pas récursive. Rien ne le dit dans le texte.
Pourquoi vaut-il mieux être root pour se lancer dans la recherche d’un fichier de configuration du système ?
Le système signale comme il se devrait qu’on ne peut pas lancer la recherche dans tel répertoire à cause des droits d’accès.
find /usr/bin -size +1M -exec ls -lh {} + \;
find lance un nouveau processus ls pour chaque résultat.
Mais en ajoutant un signe plus après les accolades, find ne lance de nouveau processus que lorsque le nombre de noms de fichiers a dépassé le nombre limite d’arguments de la ligne de commande.
cat /etc/passwd | grep bash
C’est vraiment montrer le mauvais exemple ; fournir plutôt la bonne explication.
grep "PS1" /etc/*
Le motif de noms de fichiers ne correspond pas absolument : la recherche n’est pas récursive, ….
On rappel à toutes fins utiles qu’une œuvre «libre de droit» ne peut exister par essence.
On parlera donc d’une oeuvre sous licence libre ou dans le domaine public.
En effet, la terminologie de cryptage reviendrait à chiffrer un fichier sans en connaître la clé et donc sans pouvoir le déchiffrer ensuite.
Cette assertion frise l’illogisme puisque l’opération consiste à transformer un message intelligible pour qu’il soit incompréhensible, illisible ou inaccessible. Indéchiffrable (très difficile à comprendre, à deviner ou à résoudre) dans le sens où il faut pouvoir le comprendre d’une manière ou d’une autre ; mais pas intranscriptible. En toute logique, cela signifie retrouver le message original. Sinon le message n’a aucune valeur. Les sens pourvus par les termes « cryptage » ou « crypter » tout comme « cryptologie » ou « chiffrer » ou « message codé indéchiffrable » se retrouvent dans plusieurs définitions courantes car ces termes ont des traits communs : caché et énigmatique (ce qu’il est difficile de comprendre, d’expliquer, de connaître).
On imagine que la rémunération devait être à la hauteur de l’entretien d’embauche pour accepter ce processus de recrutement :)
Tout a fait … ;)
Rhô, tu viens de me faire découvrir un truc. Je savais pas. Merci. <3
hum… Est-ce que ce commentaire ne serait pas pluôt destiné à l’autre article qui mentionne DevOps ?
Ça se discute : la commande
view(fournie dans le paquet vim) est un alias devim -Rqui ouvre le fichier en lecture seule, empêchant les modifications mais permettant navigation, coloration syntaxique et autres friandises de vim.L’avantage de pass n’est pas tant de stocker ses mots de passes avec git, mais surtout d’utiliser gpg pour les chiffrer. Ce qui permet d’avoir toute l’intégration qui va avec (clefs multiples, jetons de sécurité).
On va dire que c’est l’outil qui impose le moins de structure dans l’organisation des mdp, ce qui le rend à la fois ultra configurable, mais également réservé à un public sachant ce qu’il fait
Salut, j’ai ajouté pass dans le billet. Merci !
Je plussoie
Bien sur il manque le plus utilisé et le meilleur :
pass
https://passwordstore.org
Je n’ai pas d’expérience dans le domaine mais je pense que l’important est d’utiliser les outils qui nous conviennent. Si l’outil est complexe le temps d’apprentissage est plus long pour parvenir à une maîtrise. Il semble que cela soit fastidieux pour l’auteur de passer en revue du texte. À mon avis, c’est parce que son approche n’est pas efficace : lire du texte en séquence (e.g. Emacs Rocks! Episode 12: Working with HTML). Évidemment, il y a des avantages et des inconvénients.
C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine. Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.
J’ai rectifié pour la partie branch
main, je te remercie :)J’ai un avis mitigé sur cet article. Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…
Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.
Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).
Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)
PS: Une petite imprécision quand même,
mainn’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).Merci du repost :D
Mec.
Mes remarques peuvent paraître pointilleuses mais c’est important pour la compréhension.
Tous les fichiers de configuration de mon système dans le répertoire
/etcsont protégés en écriture pour un utilisateur courant.La commande
catcombinée avecgrepest fautive sans que l’on comprenne vraiment pourquoi. On pourrait penser que c’est plutôt équivalent àcat /etc/passwd ; grep bash /etc/passwd. L’utilisateur souhaite afficher le contenu du fichier, s’aperçoit quecatn’est pas adapté et réduit donc à l’essentiel ce qui est affiché grâce àgrep. Néanmoins, il faut savoir que des commandes fonctionnent directement avec des fichiers et dans des pipes. Cela est éventuellement plus difficile dans la manière d’exposer mais le propos n’est pas forcément plus compliqué (quoique plus fastidieux).On comprend que
grep "PS1" /etc/*est incorrect puisque le motif du nom de fichier donne accès à des fichiers quelconques (caractère de substitution étoile) dans un répertoire rempli de fichiers. Peu importe que la recherche soit poursuivie dans les sous-répertoires mais cela paraît plus logique et surtout correct./usr/bin est accessible en lecture à tout le monde.
On s’en fiche des processus lancés par -exec. C’est un cours d’introduction au shell, pas un exposé sur l’optimisation à outrance des commandes du shell.
L’exemple avec le “useless use of cat” est avant tout pédagogique. D’ailleurs il aurait suffi de lire la phrase juste après pour s’en rendre compte. C’est expliqué. Suffit de lire l’article.
Ben non, la recherche n’est pas récursive. Rien ne le dit dans le texte.
Le système signale comme il se devrait qu’on ne peut pas lancer la recherche dans tel répertoire à cause des droits d’accès.
findlance un nouveau processuslspour chaque résultat.Mais en ajoutant un signe plus après les accolades,
findne lance de nouveau processus que lorsque le nombre de noms de fichiers a dépassé le nombre limite d’arguments de la ligne de commande.C’est vraiment montrer le mauvais exemple ; fournir plutôt la bonne explication.
Le motif de noms de fichiers ne correspond pas absolument : la recherche n’est pas récursive, ….
On rappel à toutes fins utiles qu’une œuvre «libre de droit» ne peut exister par essence. On parlera donc d’une oeuvre sous licence libre ou dans le domaine public.
Cette assertion frise l’illogisme puisque l’opération consiste à transformer un message intelligible pour qu’il soit incompréhensible, illisible ou inaccessible. Indéchiffrable (très difficile à comprendre, à deviner ou à résoudre) dans le sens où il faut pouvoir le comprendre d’une manière ou d’une autre ; mais pas intranscriptible. En toute logique, cela signifie retrouver le message original. Sinon le message n’a aucune valeur. Les sens pourvus par les termes « cryptage » ou « crypter » tout comme « cryptologie » ou « chiffrer » ou « message codé indéchiffrable » se retrouvent dans plusieurs définitions courantes car ces termes ont des traits communs : caché et énigmatique (ce qu’il est difficile de comprendre, d’expliquer, de connaître).
je vais mon grammar nazi pour certains mais : https://chiffrer.info/ pour l’explication de la blague du début :)