• # Dans la même veine

    Posté par  . É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 --slave devrait être renommée, car trop connotée.

    Matricule 23415

    • [^] # Re: Dans la même veine

      Posté par  . Évalué à 3. Dernière modification le 10/06/20 à 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  . Évalué à 3.

        Salut,

        Si ça t'intrigue, le (petit) débat est .

        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  . É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  . É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  . É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  . É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  . É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  . Évalué à 2.

                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.

                • [^] # Re: Dans la même veine

                  Posté par  . Évalué à 1.

                  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.

                  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.

                  • [^] # Re: Dans la même veine

                    Posté par  . Évalué à 2.

                    Là tu joues juste à l'idiot. Node a un sens mais hyper générique

                    C’est la nomenclature officielle :

                    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.

  • # Emplacements des lettres

    Posté par  . Évalué à 5.

    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 ?

    • [^] # Re: Emplacements des lettres

      Posté par  . É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  . É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 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 ? ;)

        • [^] # Re: Emplacements des lettres

          Posté par  . É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  . É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  . É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  . Évalué à 2.

              Ce sont des serveurs avec des comptes qui ne me sont pas personnels

              Ça me semble totalement tordu comme pratique.

  • # Marrant

    Posté par  . É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 :

    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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.