Autant l’envie de virer Teamviewer et de hoster mon propre serveur de mise en relation me tente, autant installer un logiciel développé par des ressortissants chinois (si j’en crois leur noms et localisation sur Github), ben.. je suis pas chaud chaud.
N’ayant aucune compétence en Rust, je ne me vois pas relire le code pour voir s’il y a des backdoors dedans, et, encore moins, compiler les sources pour ne pas prendre directement les binaires.
Et vu qu’en plus c’est backupé par Lenovo, de sinistre mémoire quand il s’agit d’installer des backdoors et d’envoyer des informations en Chine, bof, bof…
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).
J’ai j’ajoute asdf et k9s
Et moi j’aimerais que Scarlett Johansson me demande en mariage. :o)
Merci pour l’info
J’aimerai votre avis sur le commentaire que je viens d’ajouter svp
Bonjour.
Je m’interroge beaucoup sur ce logiciel.
Autant l’envie de virer Teamviewer et de hoster mon propre serveur de mise en relation me tente, autant installer un logiciel développé par des ressortissants chinois (si j’en crois leur noms et localisation sur Github), ben.. je suis pas chaud chaud.
N’ayant aucune compétence en Rust, je ne me vois pas relire le code pour voir s’il y a des backdoors dedans, et, encore moins, compiler les sources pour ne pas prendre directement les binaires.
Et vu qu’en plus c’est backupé par Lenovo, de sinistre mémoire quand il s’agit d’installer des backdoors et d’envoyer des informations en Chine, bof, bof…
Suis-je trop parano ? Vous en pensez quoi ?
JMS
Juste une coquille dans son titre, l’outil s’appelle rustdeSk :) Sinon je valide, il fonctionne bien.
Vu les coûts cloud, c’est quasiment indispensable aujourd’hui. Une bonne chose pour leur base installée d’utilisateurs.
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 -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
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,
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).Merci du repost :D