Comme dans l'article il est mentionné à un moment une échelle allant de 0 (on accepte rien) à 10 (on accepte tout). La traduction de "How" par "À quel point" me semblait pertinente.
stakeholder = associé (ou au moins un C-level employee)
shareholder = actionnaire
Et effectivement, parfois un actionnaire est aussi un associé.
Il n'empêche que traduire "stakeholder" dans le contexte de cette phrase était assez difficile. Et je ne suis toujours pas satisfait du mot que j'ai choisi
Je préfère prôner la tolérance que la haine. Il ne faut pas mélanger religion (la philosophie) et religion (le dogme).
La bible c'est un peu différent
Dissonance cognitive. Pourquoi on pourrait pas dire "la Torah du C", ou "le Quran du C" ?
La bible ce n'est pas "le livre des livres", c'est un livre comme d'autres.
La France, et le français donc, a une culture très influencé par la chrétienté. Cela comprend les jours fériés, les expressions de langage, la manière dont on mange (je me souviens quand j'étais enfant, que le vendredi à la cantine de l'école on mangeait du poisson), etc…
Est-ce un mal ? Doit-on s'en éloigner ? Peut-être, je ne sais pas, je n'ai pas envie de débattre la dessus.
Mais ce que l'on ne peut nier, c'est que la connotation religieuse de certains mots a disparu il y a bien longtemps.
Ca ne remet aucunement en cause le fond du problème (que l'auteur de la traduction n'ai pas respecté la licence et traduit avant d'avoir eu l'autorisation cf plus bas
Cela n'arrivera plus, je ne pensais pas violer un copyright, ce n'était pas mon intention.
Mais le problème que Bruno remontait était sur la qualité de la traduction, pas sur la licence que je n'ai pas respecté.
I spoke with my manager, and we don't have a problem with you posting a translation there. We wondered if you could perhaps preface the article with the following citation instead?
Cet article, How 'open' should your open source be?, a été initialement publié sur GitHub's The ReadME Project.
Also, note the singular quotation marks around the first use of the word open in the title. :)
Réponse positive donc, si vous pouvez modifier la préface selon leur préférence, merci :)
Dire "à cet endroit tu aurais pu améliorer comme cela" c'est plus difficile.
Toi tu choisis la facilité, tu insultes et humilie et dit "c'est de la merde". Tu prend de haut et te montre très condescendant.
Ce n'est pas de la critique que tu fais, pas de la critique constructive en tout cas. Les critiques constructives, je les accepte avec plaisir, tout est bon pour s'améliorer. Les critiques du type "c'est de la merde", je les ignore. C'est du pur troll, rien de plus.
Là je me demande vraiment quelle était l'intention en publiant ce journal… Peut-être un biais lié au « karma » et aux notes de linuxfr pour activer les circuits de la récompense ?
Et bah franchement, maintenant tu me traites de pute à karma, sous quel prétexte ? sous le prétexte que ma traduction est amateure ?
Newsflash : Je suis un amateur. Je n'ai jamais prétendu être autre chose qu'un amateur. M'aurais tu dis ou je me suis planté et ce que j'aurais pu améliorer que je t'aurais remercié.
Mais la ? Va chier en fait. J'ai décidé de traduire cet article car il me semble que la gouvernance des projets open source est un sujet qui intéresse la communauté de LinuxFR, et qu'un journal aurait donné plus de visibilité qu'un simple Lien.
Vas-y moinsse, j'en ai rien à foutre du karma. Preuve en est, j'ai plussé ton commentaire irrespectueux, condescendant et méprisant.
Il y aurait eu plein de façons neutres de dire la même chose, sans sous-entendre qu'en 2005, un outil en ligne de commande c'est nul.
Je le lis plutôt comme "bien que git soit apparu en 2005, la méthode de collaboration c'est toujours les mails". git format-patch et git send-mail en sont la preuve.
Faux. Pull request, ça veut dire demande de git pull, et ça existait déjà depuis que Git existe
Oui bon, il fallait bien comprendre ici que l'on parlait de l'interface graphique qui te permet de le faire en quelques clics au lieu d'envoyer un patch par mail.
Mais de grâce, cessez de prétendre que Github a inventé la PR.
Github a bien inventé une interface graphique pour collaborer sur Git.
J'ai contacté l'auteur pour avoir une confirmation explicite mais il est dans une autre timezone, si d'ici demain j'ai pas de réponse, je demanderai aux mods de takedown l'article.
J'ai le markdown en local si je reçois une réponse positive plus tard que ça.
Il me semblait qu'il s'agissait de la licence des contenus de Github, pas la licence des règles à proprement parlé. Les "terms and conditions" de Github sont très dur à naviguer.
Dans tout les cas, il me semble également que donner un lien vers l'article original est suffisant selon la loi américaine (qui serait celle en vigueur vu que Github est une entreprise américaine), mais je ne suis pas avocat.
Parallèlement, je suis curieux de savoir pourquoi tu mets le mot "traduit" entre guillemets…
J'avais fait quelques recherches en amont, il semblerait que le contenu publié par Github soit sous licence CC0-1.0 ( https://github.com/github/site-policy#license ), cela exclut l'usage de la marque "Github".
Leur nom est utilisé pour grep le git log, dans 99% des cas tu as la représentation visuelle (en explorant Github/Gitlab).
Et parlante ou pas, au bout d'un certain temps (relativement court), cela devient un réflexe. C'est juste une question d'habitude (mais je comprends que les gens n'aiment pas changer leurs habitudes).
Honnêtement :
🐛 un bug
✨ une fonctionnalité
👷 de la CI/CD
🔧 de la conf
👕 fix de problème de linter
📝 de la documentation
🚧 du Work In Progress
➕/➖ ajout/suppression de dépendance
⬆️ mise à jour de dépendance
📌 mise à jour du lockfile (yarn.lock, poetry.lock, Cargo.lock, …)
🔖 bump de version du projet
C'est ceux que j'utilise le plus, et c'est facile à retenir. Et quand j'en oublis, un petit détour par https://gitmoji.dev avec ctrl+f répond a ma question en 30s.
J'adore gitmoji. Cela rend le git log bien plus facile à lire.
Je l'utilise dans les titres d'issues et de PR, ainsi que dans les checklist sur ces dernières. Exemple :
Title: :refactor: Simplify ansible playbook for nginx modsec policies
Description:
This PR provides the following changes:
[x] :truck: Rename template files for clarity
[x] :recycle: Render modsec rules with a Jinja2 template instead of perl scripts
[x] :fire: Remove obsolete Perl scripts
[x] :wrench: Add new hosts to the reverse-proxy hostgroup
Mes PRs font ainsi office de "Architecture Decision Record", pratique pour l'onboarding. On s'attend à ce que le git log ressemble plus ou moins à la checklist, etc…
De plus, le format :bug:, :sparkles:, etc… est toujours facilement greppable.
Dans la pratique comment ça se passe, tu a un outil pour avoir le smiley ou c'est par copier/coller avec le site ?
Github et Gitlab supportent le format :nom de l'emoji: :
:bug: 🐛
:sparkles: ✨
Ils le supportent aussi dans les titres de PR/Issues.
J'imagine que ça permet aussi de gagner quelques caractères dans la première ligne de message de commit qu'il est conseillé de garder sous les 50 caractères.
Github et Gitlab vont comprendre l'emoji comme un seul caractères. Bon ça fait un comportement différent de git log, mais c'est pas trop grave.
Perso, je préfère gitmoji à conventional commit. Une image est beaucoup plus facile à identifier que du texte. Et le format :bug: permet toujours de grep le git log assez facilement (un des avantages de conventional commit).
Mais bon, je note comment les gens préfèrent moinsser, et me tourner en ridicule, au lieu de répondre à la question que j'ai posé concernant les liseuses d'écrans pour les mal voyants.
On a @barmic qui me fait la leçon sur le daltonisme.
La majorité des personnes qui ont répondu à mon commentaire ont choisit de me tourner en ridicule (pas toi dans ta toute première réponse, mais tu as choisi d'être condescendant dans tes réponses suivantes) et d'ignorer une question qui reste encore sans réponse.
Non, tu n'avais pas besoin de prendre des pincettes, tu pouvais simplement ignorer la partie "code couleur" qui a déjà été démonté par moi même (soulignant dans le premier message les daltoniens) et les réponses suivantes (je compte que celles qui ne sont pas du troll/foutage de gueule, et cela inclut ta première réponse), tu n'avais pas besoin "d'approfondir" car il n'y a rien à approfondir.
En tout cas, ma question sur les liseuses d'écran est toujours sans réponse. On se plaint que le cadenas est une fausse information, mais cela ne concerne que les "bien-voyants".
D'autres t'ont rappelé que même sans se poser la question des lecteurs d'écran, se baser sur la couleur est un problème pour les daltoniens (ce qui représente ~5% de la population).
D'autres ont simplement répété ce que j'avais déjà dit dans mon message original :
Bon après, faudra peut-être trouver d'autres couleurs pour les daltoniens.
L'icône de cadenas ne donne qu'une seule information. La ou un code couleur aurait pu donner plus d'informations.
C'était une idée comme ça, pas vraiment réfléchie.
Mais bon, je note comment les gens préfèrent moinsser, et me tourner en ridicule, au lieu de répondre à la question que j'ai posé concernant les liseuses d'écrans pour les mal voyants.
Pas de cadenas = HTTP
Cadenas rouge = HTTPS mais certificat invalide
Cadenas orange = HTTPS mais certificat expiré
Cadenas vert = HTTPS et certificat valide
Cadenas bleu = HTTPS et certificat valide ET reconnu par les CA de la machine
Bon après, faudra peut-être trouver d'autres couleurs pour les daltoniens.
D'ailleurs, autre question. Une icone c'est bien, mais pour les malvoyants ? Est-ce que la liseuse d'écran donne l'information ?
La différence entre un bon op et un mauvais op, c'est que le mauvais op, il voit une commande, il mets "sudo" devant. Alors que le bon op, il voit une commande… il mets "sudo" devant, mais c'est un bon op.
Oui exact, il faudrait que j'aille regarder le manuel des regex pour retrouver le même comportement (-E "regex"), alors qu'il est plus simple de composer les deux.
[^] # Re: Si j'ai bien compris...
Posté par David Delassus (site web personnel) . En réponse au lien why I left Rust. Évalué à 4. Dernière modification le 30 mai 2023 à 12:47.
Dans le monde académique, oui. Cela démontre :
Cela donne un profond sentiment d'amateurisme et de "teenage drama" dont tout conférencier se passerait bien.
C'est comme si l'auteur d'un papier scientifique te demandait de l'aider à écrire le papier, pour ensuite te dire une fois complété :
Après, je sais pas si on est dans du "académique", mais on est très certainement dans du "teenage drama".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pinaillage sur le titre
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 6.
Comme dans l'article il est mentionné à un moment une échelle allant de 0 (on accepte rien) à 10 (on accepte tout). La traduction de "How" par "À quel point" me semblait pertinente.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Translator 2: Judgment Day
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 2.
Effectivement, je me suis gouré.
Et effectivement, parfois un actionnaire est aussi un associé.
Il n'empêche que traduire "stakeholder" dans le contexte de cette phrase était assez difficile. Et je ne suis toujours pas satisfait du mot que j'ai choisi
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 2.
Oui, erreur de ma part, je ne fais jamais attention à cette case à cocher.
La traduction étant un travail dérivé, je n'ai reçu que le droit de la distribuer via ce site, je ne peux donc pas dispenser d'autres droits.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Translator 2: Judgment Day
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 6.
Je préfère prôner la tolérance que la haine. Il ne faut pas mélanger religion (la philosophie) et religion (le dogme).
Dissonance cognitive. Pourquoi on pourrait pas dire "la Torah du C", ou "le Quran du C" ?
La bible ce n'est pas "le livre des livres", c'est un livre comme d'autres.
La France, et le français donc, a une culture très influencé par la chrétienté. Cela comprend les jours fériés, les expressions de langage, la manière dont on mange (je me souviens quand j'étais enfant, que le vendredi à la cantine de l'école on mangeait du poisson), etc…
Est-ce un mal ? Doit-on s'en éloigner ? Peut-être, je ne sais pas, je n'ai pas envie de débattre la dessus.
Mais ce que l'on ne peut nier, c'est que la connotation religieuse de certains mots a disparu il y a bien longtemps.
https://www.topito.com/top-expressions-origine-religieuse
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 7.
Cela n'arrivera plus, je ne pensais pas violer un copyright, ce n'était pas mon intention.
Mais le problème que Bruno remontait était sur la qualité de la traduction, pas sur la licence que je n'ai pas respecté.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 8. Dernière modification le 15 mai 2023 à 19:12.
J'ai reçu la réponse de l'auteur :
Réponse positive donc, si vous pouvez modifier la préface selon leur préférence, merci :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 10.
Dire "c'est de la merde" c'est facile.
Dire "à cet endroit tu aurais pu améliorer comme cela" c'est plus difficile.
Toi tu choisis la facilité, tu insultes et humilie et dit "c'est de la merde". Tu prend de haut et te montre très condescendant.
Ce n'est pas de la critique que tu fais, pas de la critique constructive en tout cas. Les critiques constructives, je les accepte avec plaisir, tout est bon pour s'améliorer. Les critiques du type "c'est de la merde", je les ignore. C'est du pur troll, rien de plus.
Et bah franchement, maintenant tu me traites de pute à karma, sous quel prétexte ? sous le prétexte que ma traduction est amateure ?
Newsflash : Je suis un amateur. Je n'ai jamais prétendu être autre chose qu'un amateur. M'aurais tu dis ou je me suis planté et ce que j'aurais pu améliorer que je t'aurais remercié.
Mais la ? Va chier en fait. J'ai décidé de traduire cet article car il me semble que la gouvernance des projets open source est un sujet qui intéresse la communauté de LinuxFR, et qu'un journal aurait donné plus de visibilité qu'un simple Lien.
Vas-y moinsse, j'en ai rien à foutre du karma. Preuve en est, j'ai plussé ton commentaire irrespectueux, condescendant et méprisant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pull request
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 2.
Je le lis plutôt comme "bien que git soit apparu en 2005, la méthode de collaboration c'est toujours les mails".
git format-patchetgit send-mailen sont la preuve.Oui bon, il fallait bien comprendre ici que l'on parlait de l'interface graphique qui te permet de le faire en quelques clics au lieu d'envoyer un patch par mail.
Github a bien inventé une interface graphique pour collaborer sur Git.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 2.
Retirer / supprimer
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 2.
J'ai contacté l'auteur pour avoir une confirmation explicite mais il est dans une autre timezone, si d'ici demain j'ai pas de réponse, je demanderai aux mods de takedown l'article.
J'ai le markdown en local si je reçois une réponse positive plus tard que ça.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 3.
Comme dit plus haut, il me semble que la loi américaine autorise les traductions avec attribution.
Oui je veux bien savoir pourquoi tu insinue que j'ai pas passé 2h à traduire l'article et pourquoi tu te montres si condescendant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 1.
Il me semblait qu'il s'agissait de la licence des contenus de Github, pas la licence des règles à proprement parlé. Les "terms and conditions" de Github sont très dur à naviguer.
Dans tout les cas, il me semble également que donner un lien vers l'article original est suffisant selon la loi américaine (qui serait celle en vigueur vu que Github est une entreprise américaine), mais je ne suis pas avocat.
Parallèlement, je suis curieux de savoir pourquoi tu mets le mot "traduit" entre guillemets…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 1.
J'avais fait quelques recherches en amont, il semblerait que le contenu publié par Github soit sous licence CC0-1.0 ( https://github.com/github/site-policy#license ), cela exclut l'usage de la marque "Github".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Jamais pratiqué
Posté par David Delassus (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 3. Dernière modification le 11 mai 2023 à 11:35.
Leur nom est utilisé pour grep le git log, dans 99% des cas tu as la représentation visuelle (en explorant Github/Gitlab).
Et parlante ou pas, au bout d'un certain temps (relativement court), cela devient un réflexe. C'est juste une question d'habitude (mais je comprends que les gens n'aiment pas changer leurs habitudes).
Honnêtement :
C'est ceux que j'utilise le plus, et c'est facile à retenir. Et quand j'en oublis, un petit détour par https://gitmoji.dev avec ctrl+f répond a ma question en 30s.
Exemple ici : https://github.com/linkdd/tricorder/commits/main
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Des emojis partout SVP 🙂🙂🙂
Posté par David Delassus (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 5.
J'adore gitmoji. Cela rend le git log bien plus facile à lire.
Je l'utilise dans les titres d'issues et de PR, ainsi que dans les checklist sur ces dernières. Exemple :
Title: :refactor: Simplify ansible playbook for nginx modsec policies
Description:
This PR provides the following changes:
Mes PRs font ainsi office de "Architecture Decision Record", pratique pour l'onboarding. On s'attend à ce que le git log ressemble plus ou moins à la checklist, etc…
De plus, le format
:bug:,:sparkles:, etc… est toujours facilement greppable.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Jamais pratiqué
Posté par David Delassus (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 3. Dernière modification le 11 mai 2023 à 02:08.
Github et Gitlab supportent le format
:nom de l'emoji:::bug:🐛:sparkles:✨Ils le supportent aussi dans les titres de PR/Issues.
Github et Gitlab vont comprendre l'emoji comme un seul caractères. Bon ça fait un comportement différent de git log, mais c'est pas trop grave.
Perso, je préfère gitmoji à conventional commit. Une image est beaucoup plus facile à identifier que du texte. Et le format
:bug:permet toujours de grep le git log assez facilement (un des avantages de conventional commit).https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quid d'un code couleur ?
Posté par David Delassus (site web personnel) . En réponse au lien L'icône cadenas pour HTTPS n'était pas une si bonne idée en pratique (et HTTPS à 95%). Évalué à -1.
@Ysabeau
@GG
@Big Pete
@Bruno
Et enfin, en réponse à :
On a @barmic qui me fait la leçon sur le daltonisme.
La majorité des personnes qui ont répondu à mon commentaire ont choisit de me tourner en ridicule (pas toi dans ta toute première réponse, mais tu as choisi d'être condescendant dans tes réponses suivantes) et d'ignorer une question qui reste encore sans réponse.
Non, tu n'avais pas besoin de prendre des pincettes, tu pouvais simplement ignorer la partie "code couleur" qui a déjà été démonté par moi même (soulignant dans le premier message les daltoniens) et les réponses suivantes (je compte que celles qui ne sont pas du troll/foutage de gueule, et cela inclut ta première réponse), tu n'avais pas besoin "d'approfondir" car il n'y a rien à approfondir.
En tout cas, ma question sur les liseuses d'écran est toujours sans réponse. On se plaint que le cadenas est une fausse information, mais cela ne concerne que les "bien-voyants".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quid d'un code couleur ?
Posté par David Delassus (site web personnel) . En réponse au lien L'icône cadenas pour HTTPS n'était pas une si bonne idée en pratique (et HTTPS à 95%). Évalué à -7.
Merci de me prendre pour un con qui n'est pas au courant. Et merci d'étaler ta culture. C'était pas le sujet.
Mais bon, sur TrollFR, on aime chercher la petite bête est péter plus haut que son cul, tout en continuant d'éviter la question.
J'arrête de discuter avec toi, c'est pas la peine.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quid d'un code couleur ?
Posté par David Delassus (site web personnel) . En réponse au lien L'icône cadenas pour HTTPS n'était pas une si bonne idée en pratique (et HTTPS à 95%). Évalué à 0.
D'autres ont simplement répété ce que j'avais déjà dit dans mon message original :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quid d'un code couleur ?
Posté par David Delassus (site web personnel) . En réponse au lien L'icône cadenas pour HTTPS n'était pas une si bonne idée en pratique (et HTTPS à 95%). Évalué à 1.
L'icône de cadenas ne donne qu'une seule information. La ou un code couleur aurait pu donner plus d'informations.
C'était une idée comme ça, pas vraiment réfléchie.
Mais bon, je note comment les gens préfèrent moinsser, et me tourner en ridicule, au lieu de répondre à la question que j'ai posé concernant les liseuses d'écrans pour les mal voyants.
J'avais oublié que j'étais sur TrollFR.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Quid d'un code couleur ?
Posté par David Delassus (site web personnel) . En réponse au lien L'icône cadenas pour HTTPS n'était pas une si bonne idée en pratique (et HTTPS à 95%). Évalué à -1.
Pas de cadenas = HTTP
Cadenas rouge = HTTPS mais certificat invalide
Cadenas orange = HTTPS mais certificat expiré
Cadenas vert = HTTPS et certificat valide
Cadenas bleu = HTTPS et certificat valide ET reconnu par les CA de la machine
Bon après, faudra peut-être trouver d'autres couleurs pour les daltoniens.
D'ailleurs, autre question. Une icone c'est bien, mais pour les malvoyants ? Est-ce que la liseuse d'écran donne l'information ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Doas
Posté par David Delassus (site web personnel) . En réponse au lien sudo & su Being Rewritten In Rust For Memory Safety - phoronix. Évalué à 5.
La différence entre un bon op et un mauvais op, c'est que le mauvais op, il voit une commande, il mets "sudo" devant. Alors que le bon op, il voit une commande… il mets "sudo" devant, mais c'est un bon op.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Doas
Posté par David Delassus (site web personnel) . En réponse au lien sudo & su Being Rewritten In Rust For Memory Safety - phoronix. Évalué à 2.
opérateur. C'est un peu un admin sys quoi.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Doas
Posté par David Delassus (site web personnel) . En réponse au lien sudo & su Being Rewritten In Rust For Memory Safety - phoronix. Évalué à 2.
Oui exact, il faudrait que j'aille regarder le manuel des regex pour retrouver le même comportement (
-E "regex"), alors qu'il est plus simple de composer les deux.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg