Ne pas oublier les arguments. C'est important les arguments dans une commande.
Le dernier exemple qui me vient en tête est celui d'un inconnu de ma part qui déboule sur une liste de diffusion (pas la bonne au passage, mais passons) en disant que l'option --slave devrait être renommée, car trop connotée.
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 10 juin 2020 à 12:53.
C'est un débat hyper compliqué. Je comprends que ça puisse choquer, d'autant plus que l'esclavage existe toujours et que la vie de nombreuses communautées restent impactées par l'esclavage passé.
Mais en même temps ces mots expliquent tellement bien le principe et sont sans équivoque. Et on parle dans ce cas de machine/programmes qui n'ont pas de souffrance ou de sentiments vis à vis de ça donc il n'y a pas ce côté négatif et péjoratif à asservir un programme par un autre.
Alors j'imagine qu'on peut remplacer par --boss / --subordinate, ce sera toujours mieux que --pimp / --whore.
Les mots ne manquent pas, ni en anglais, ni en français, continuer à utiliser master/slave aujourd’hui c’est vraiment ne pas avoir envie de faire autrement.
Après j'ai du mal à voir en quoi c'est réellement un problème en pratique puisqu'on utilise réellement les machines et les robots comme des esclaves et qu'il n'y a pas de problème puisqu'elles n'en souffrent pas. Si le problème c'est le rapport à une histoire, personne ne s'émeu contre l'usage des verbes servir et du mot serveur, que ce soit sur ordinateur ou dans un bar et dont l'origine est assez commune.
Pour une infrastructure répliquée/distribuée tu as « primary / secondary » ou « primary / replica ».
Kubernetes utilise par exemple « controller / worker » ou « controller / node ».
Dans Git tu peux appeler ta branche par défaut main ou mainline (j’utilise main personnellement).
C’est pas quelque chose de récent et une recherche dans ton moteur de recherche préféré t’aurai permis de trouver des synonyme en moins de temps que ça ne m’a pris d’écrire ce commentaire.
Dans le cas de primary / secondary et/ou replica ce ne sont pas forcément des synonymes car pas les mêmes notions.
D'ailleurs si slave est un problème, je pense que master n'en ai pas un car c'est un mot qui a moultes signification et dans le cas de git ça n'a rien à voir avec une relation maitre-esclave, donc virer master est un peu inutile. node c'est beaucoup trop générique et ne veut rien dire. On parle d'ailleurs de control-plane node.
Worker est pas mal comme remplacement de slave par contre effectivement et le seul que je vois assez proche sémantiquement sans y avoir la notion d'asservissement par la contrainte.
D'ailleurs si slave est un problème, je pense que master n'en ai pas un car c'est un mot qui a moultes signification et dans le cas de git ça n'a rien à voir avec une relation maitre-esclave, donc virer master est un peu inutile.
On tourne en rond.
C’est un débat qui a lieu depuis des années, mais si tu penses que ça n’a pas d’importance, grand bien t’en fasse.
node c'est beaucoup trop générique et ne veut rien dire. On parle d'ailleurs de control-plane node.
Dans le contexte de Kubernetes, le mot node a du sens. Si tu pense que dans ton contexte ça n’en a pas, grand bien te fasse.
C’est un débat qui a lieu depuis des années, mais si tu penses que ça n’a pas d’importance, grand bien t’en fasse.
Non. Autant Master dans un cluster avec un système de noeud asservi par le master a une relation directe avec l'esclavage et je comprends que ça puisse choquer. Autant dans git master est utilisé comme on parle du master d'un disque et c'est en relation directe avec l'utilisation de maître/master dans son sens originel.
Tu serais aussi pour interdire l'usage du mot maître d'hôtel ou du master universitaire ?
Dans le contexte de Kubernetes, le mot node a du sens. Si tu pense que dans ton contexte ça n’en a pas, grand bien te fasse.
Là tu joues juste à l'idiot. Node a un sens mais hyper générique, ce n'est pas pour rien qu'on parle de controller-node ou de worker-node. En lui même il ne signifique le fait que c'est un membre individuel d'un grand cluster, pas son rôle dans le cluster.
Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node contains the services necessary to run Pods , managed by the control plane .—Page Nodes dans la documentation de Kubernetes
Donc dans ce contexte, utiliser node, plutôt que slave, worker ou minion ça a du sens. C’est le cas aussi dans OpenStack visiblement. La doc de Proxmox VE parle aussi de nodes. Galera parle de node également.
Bref, peut-être que dans d’autre contextes ça n’a pas de sens de parler de node, mais dans bien des cas c’est un bon replaçant de slave.
L’article est très bon, mais certains arguments partent du principe que les lettres sont sur un clavier qwerty. easy_install est plutôt facile à taper sur mon BÉPO (prosélytisme intented).
Mais c'est sûr que ça vaut le coup d'y réfléchir à deux fois.
Seulement voilà : comment être sûr que sa petite commande faite à l'arrache un soir de beuverie hackathon va devenir le prochain grep ou ls ?
Cet article oublie un peu l'existence des alias qui nous affranchit un peu de tout ça.
Moi je me dis juste que tout dépend si il est possible de décrire l'intérêt de la commande en moins d'une quinzaine de lettres. Par exemple kubectl c'est un peu long mais c'est pas grave en interactif tous les admins kubernetes vont utiliser un alias k.
Dans le cas de git, c'est un distributed version control system. C'est trop long à dire, dvcs n'est pas mega parlant. Du coup git ça va, d'autant plus qu'on peut lui configurer des alias pour les sous-commandes. Mais en même temps ça me dérange un peu parce que ce n'est pas une commande historique ni posix et qu'au final il aurait très bien pu être plus long que ça n'aurait pas dérangé et beaucoup de monde vont privilégier des alias shell plutôt que des alias git:
des exemples
gp au lieu de git p qui aurait été un alias pour git pull
gco au lieu de git co qui aurait été un alias pour git checkout
gst au lieu de git s ou git st qui aurait été un alias pour git status
ga pour git add
gcm au lieu de git cm qui aurait été un alias pour git commit -m
glo au lieu de git lo qui aurait été n alias pour git log --oneline
Au final un nom long et expressif est toujours utile pour la compréhension des scripts, d'autant plus qu'on va quasi toujours le passer sous forme de fonction ou variable.
Personnellement, je ne travaille pas avec des alias, c'est ingérable. J'ai :
- Mon ordinateur fixe
- Un ordinateur portable du boulot
- Un ancien ordinateur de boulot qui me sert pour la visioconférence
- L’ordinateur de ma femme
- 250 (j’ai pas compté, c'est sûrement plus) serveurs administrés avec des distributions Linux différentes dans des versions différentes
Donc si j'ai un alias sur l'un d'entre eux, il faut que je me souvienne duquel. La mémoire musculaire ne permet pas de faire ça, et ça me rajoute une surcharge mentale.
Par contre, mon shell fish fait ça super bien pour moi. Je tape deux lettres et il m'affiche en ton pastel le reste de la dernière commande qui correspondait au même début, en excluant les commandes non pertinentes (par exemples avec des fichiers qui n'existent plus dans le cas de rm). C'est pas cool ça ? ;)
C'est pas comme si c'était d'une complexité absolue de répliquer des profiles shells sur n machines et le moins que l'on puisse dire, c'est qu'on a le choix des armes. D'autant plus que ton shell favori, fish, n'est installé par défaut sur aucune distrib que je connaisse.
Bref les alias ce n'est pas forcément ingérable, d'autant plus qu'on se connecte de moins en moins directement aux machines administrées.
C’est de la bidouille. C’est cool si tu veux tout personnaliser aux petits oignons et si tu utilises tes trucs à toi perpétuellement, mais ça restera personnel, tout le monde pourra avoir des habitudes différentes …
C’est un pis aller pour remplacer une bonne conception initiale partagée. Qui permet d’enseigner et de former plus facilement les gens aux bonnes habitudes et permet de créer une culture commune plus facilement.
C'est vrai que mon shell n'est pas installé par défaut, c'est parfois « gênant ».
Mais non, je ne peux pas répliquer les alias. Ce sont des serveurs avec des comptes qui ne me sont pas personnels, et je ne vais pas avoir un fichier à sourcer à chaque fois que je m'y connecte. En plus, ce sont des machines qui sont réinstallés de temps à autre, sans que je puisse le savoir.
J’ai enfin pris le temps de lire l’article et il est vraiment drôle.
Il y a un point qui mérite un exemple à mon avis :
Don't depend on your command's name to determine its scope. Keep those decisions separate.
$ ln -s /usr/bin/pgrep pkill
$ ./pkill --version
pkill from procps-ng 3.3.16
$ ln -s /usr/bin/pkill foobar
$ ./foobar --version
foobar from procps-ng 3.3.16
$ ./foobar -h
Usage:
foobar [options] <pattern>
Options:
-d, --delimiter <string> specify output delimiter
-l, --list-name list PID and process name
-a, --list-full list PID and full command line
-v, --inverse negates the matching
-w, --lightweight list all TID
-c, --count count of matching processes
-f, --full use full process name to match
-g, --pgroup <PGID,...> match listed process group IDs
-G, --group <GID,...> match real group IDs
-i, --ignore-case match case insensitively
-n, --newest select most recently started
-o, --oldest select least recently started
-P, --parent <PPID,...> match only child processes of the given parent
-s, --session <SID,...> match session IDs
-t, --terminal <tty,...> match by controlling terminal
-u, --euid <ID,...> match by effective IDs
-U, --uid <ID,...> match by real IDs
-x, --exact match exactly with the command name
-F, --pidfile <file> read PIDs from file
-L, --logpidfile fail if PID file is not locked
-r, --runstates <state> match runstates [D,S,Z,...]
--ns <PID> match the processes that belong to the same
namespace as <pid>
--nslist <ns,...> list which namespaces will be considered for
the --ns option.
Available namespaces: ipc, mnt, net, pid, user, uts
-h, --help display this help and exit
-V, --version output version information and exit
For more details see pgrep(1).
$ ./foobar -laf init
1 /sbin/init splash
# Dans la même veine
Posté par _kaos_ . Évalué à 3.
Salut,
Ne pas oublier les arguments. C'est important les arguments dans une commande.
Le dernier exemple qui me vient en tête est celui d'un inconnu de ma part qui déboule sur une liste de diffusion (pas la bonne au passage, mais passons) en disant que l'option
--slavedevrait être renommée, car trop connotée.Matricule 23415
[^] # Re: Dans la même veine
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 10 juin 2020 à 12:53.
C'est un débat hyper compliqué. Je comprends que ça puisse choquer, d'autant plus que l'esclavage existe toujours et que la vie de nombreuses communautées restent impactées par l'esclavage passé.
Mais en même temps ces mots expliquent tellement bien le principe et sont sans équivoque. Et on parle dans ce cas de machine/programmes qui n'ont pas de souffrance ou de sentiments vis à vis de ça donc il n'y a pas ce côté négatif et péjoratif à asservir un programme par un autre.
Alors j'imagine qu'on peut remplacer par --boss / --subordinate, ce sera toujours mieux que --pimp / --whore.
[^] # Re: Dans la même veine
Posté par _kaos_ . Évalué à 3.
Salut,
Si ça t'intrigue, le (petit) débat est là.
Bon, c'est pas très long, parce qu'en général tout le monde reste cool sur la liste.
Matricule 23415
[^] # Re: Dans la même veine
Posté par Psychofox (Mastodon) . Évalué à 2.
Oui et au final c'est vrai que dans ce cas précis, l'argument en question était mal commenté.
[^] # Re: Dans la même veine
Posté par Anonyme . Évalué à 1.
Les mots ne manquent pas, ni en anglais, ni en français, continuer à utiliser master/slave aujourd’hui c’est vraiment ne pas avoir envie de faire autrement.
[^] # Re: Dans la même veine
Posté par Psychofox (Mastodon) . Évalué à 1.
Des exemples ?
Après j'ai du mal à voir en quoi c'est réellement un problème en pratique puisqu'on utilise réellement les machines et les robots comme des esclaves et qu'il n'y a pas de problème puisqu'elles n'en souffrent pas. Si le problème c'est le rapport à une histoire, personne ne s'émeu contre l'usage des verbes servir et du mot serveur, que ce soit sur ordinateur ou dans un bar et dont l'origine est assez commune.
[^] # Re: Dans la même veine
Posté par Anonyme . Évalué à 2.
Pour une infrastructure répliquée/distribuée tu as « primary / secondary » ou « primary / replica ».
Kubernetes utilise par exemple « controller / worker » ou « controller / node ».
Dans Git tu peux appeler ta branche par défaut main ou mainline (j’utilise main personnellement).
C’est pas quelque chose de récent et une recherche dans ton moteur de recherche préféré t’aurai permis de trouver des synonyme en moins de temps que ça ne m’a pris d’écrire ce commentaire.
[^] # Re: Dans la même veine
Posté par Psychofox (Mastodon) . Évalué à 1.
Dans le cas de primary / secondary et/ou replica ce ne sont pas forcément des synonymes car pas les mêmes notions.
D'ailleurs si slave est un problème, je pense que master n'en ai pas un car c'est un mot qui a moultes signification et dans le cas de git ça n'a rien à voir avec une relation maitre-esclave, donc virer master est un peu inutile. node c'est beaucoup trop générique et ne veut rien dire. On parle d'ailleurs de control-plane node.
Worker est pas mal comme remplacement de slave par contre effectivement et le seul que je vois assez proche sémantiquement sans y avoir la notion d'asservissement par la contrainte.
[^] # Re: Dans la même veine
Posté par Anonyme . Évalué à 2.
On tourne en rond.
C’est un débat qui a lieu depuis des années, mais si tu penses que ça n’a pas d’importance, grand bien t’en fasse.
Dans le contexte de Kubernetes, le mot node a du sens. Si tu pense que dans ton contexte ça n’en a pas, grand bien te fasse.
[^] # Re: Dans la même veine
Posté par Psychofox (Mastodon) . Évalué à 1.
Non. Autant Master dans un cluster avec un système de noeud asservi par le master a une relation directe avec l'esclavage et je comprends que ça puisse choquer. Autant dans git master est utilisé comme on parle du master d'un disque et c'est en relation directe avec l'utilisation de maître/master dans son sens originel.
Tu serais aussi pour interdire l'usage du mot maître d'hôtel ou du master universitaire ?
Là tu joues juste à l'idiot. Node a un sens mais hyper générique, ce n'est pas pour rien qu'on parle de controller-node ou de worker-node. En lui même il ne signifique le fait que c'est un membre individuel d'un grand cluster, pas son rôle dans le cluster.
[^] # Re: Dans la même veine
Posté par Anonyme . Évalué à 2.
C’est la nomenclature officielle :
Donc dans ce contexte, utiliser node, plutôt que slave, worker ou minion ça a du sens. C’est le cas aussi dans OpenStack visiblement. La doc de Proxmox VE parle aussi de nodes. Galera parle de node également.
Bref, peut-être que dans d’autre contextes ça n’a pas de sens de parler de node, mais dans bien des cas c’est un bon replaçant de slave.
# Emplacements des lettres
Posté par Glandos . Évalué à 5.
L’article est très bon, mais certains arguments partent du principe que les lettres sont sur un clavier qwerty.
easy_installest plutôt facile à taper sur mon BÉPO (prosélytisme intented).Mais c'est sûr que ça vaut le coup d'y réfléchir à deux fois.
Seulement voilà : comment être sûr que sa petite commande faite à l'arrache un soir de
beuveriehackathon va devenir le prochaingrepouls?[^] # Re: Emplacements des lettres
Posté par Psychofox (Mastodon) . Évalué à 2.
Cet article oublie un peu l'existence des alias qui nous affranchit un peu de tout ça.
Moi je me dis juste que tout dépend si il est possible de décrire l'intérêt de la commande en moins d'une quinzaine de lettres. Par exemple kubectl c'est un peu long mais c'est pas grave en interactif tous les admins kubernetes vont utiliser un alias k.
Dans le cas de git, c'est un distributed version control system. C'est trop long à dire, dvcs n'est pas mega parlant. Du coup git ça va, d'autant plus qu'on peut lui configurer des alias pour les sous-commandes. Mais en même temps ça me dérange un peu parce que ce n'est pas une commande historique ni posix et qu'au final il aurait très bien pu être plus long que ça n'aurait pas dérangé et beaucoup de monde vont privilégier des alias shell plutôt que des alias git:
des exemples
gp au lieu de git p qui aurait été un alias pour git pull
gco au lieu de git co qui aurait été un alias pour git checkout
gst au lieu de git s ou git st qui aurait été un alias pour git status
ga pour git add
gcm au lieu de git cm qui aurait été un alias pour git commit -m
glo au lieu de git lo qui aurait été n alias pour git log --oneline
Au final un nom long et expressif est toujours utile pour la compréhension des scripts, d'autant plus qu'on va quasi toujours le passer sous forme de fonction ou variable.
[^] # Re: Emplacements des lettres
Posté par Glandos . Évalué à 4.
Personnellement, je ne travaille pas avec des alias, c'est ingérable. J'ai :
- Mon ordinateur fixe
- Un ordinateur portable du boulot
- Un ancien ordinateur de boulot qui me sert pour la visioconférence
- L’ordinateur de ma femme
- 250 (j’ai pas compté, c'est sûrement plus) serveurs administrés avec des distributions Linux différentes dans des versions différentes
Donc si j'ai un alias sur l'un d'entre eux, il faut que je me souvienne duquel. La mémoire musculaire ne permet pas de faire ça, et ça me rajoute une surcharge mentale.
Par contre, mon shell
fishfait ça super bien pour moi. Je tape deux lettres et il m'affiche en ton pastel le reste de la dernière commande qui correspondait au même début, en excluant les commandes non pertinentes (par exemples avec des fichiers qui n'existent plus dans le cas derm). C'est pas cool ça ? ;)[^] # Re: Emplacements des lettres
Posté par Psychofox (Mastodon) . Évalué à 2.
C'est pas comme si c'était d'une complexité absolue de répliquer des profiles shells sur n machines et le moins que l'on puisse dire, c'est qu'on a le choix des armes. D'autant plus que ton shell favori, fish, n'est installé par défaut sur aucune distrib que je connaisse.
Bref les alias ce n'est pas forcément ingérable, d'autant plus qu'on se connecte de moins en moins directement aux machines administrées.
[^] # Re: Emplacements des lettres
Posté par Thomas Douillard . Évalué à 3.
C’est de la bidouille. C’est cool si tu veux tout personnaliser aux petits oignons et si tu utilises tes trucs à toi perpétuellement, mais ça restera personnel, tout le monde pourra avoir des habitudes différentes …
C’est un pis aller pour remplacer une bonne conception initiale partagée. Qui permet d’enseigner et de former plus facilement les gens aux bonnes habitudes et permet de créer une culture commune plus facilement.
[^] # Re: Emplacements des lettres
Posté par Glandos . Évalué à 2.
C'est vrai que mon shell n'est pas installé par défaut, c'est parfois « gênant ».
Mais non, je ne peux pas répliquer les alias. Ce sont des serveurs avec des comptes qui ne me sont pas personnels, et je ne vais pas avoir un fichier à sourcer à chaque fois que je m'y connecte. En plus, ce sont des machines qui sont réinstallés de temps à autre, sans que je puisse le savoir.
[^] # Re: Emplacements des lettres
Posté par Psychofox (Mastodon) . Évalué à 2.
Ça me semble totalement tordu comme pratique.
# Marrant
Posté par Anonyme . Évalué à 2.
J’ai enfin pris le temps de lire l’article et il est vraiment drôle.
Il y a un point qui mérite un exemple à mon avis :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.