If "Master/Slave" terminology in computing sounds bad now, why not change it to "Dom/Sub"? - eviltoast

It sounds way less offensive to those who decry the original terminology’s problematic roots but still keeps its meaning intact.

    • ScreamingFirehawk@feddit.uk
      link
      fedilink
      arrow-up
      34
      arrow-down
      2
      ·
      4 months ago

      It’s all good and well until you start working in a repo that has both master and main branches for some reason, and it is not clear which is actually the master/main branch.

      • MummifiedClient5000@feddit.dk
        link
        fedilink
        English
        arrow-up
        41
        arrow-down
        1
        ·
        4 months ago

        Then you’re working in an idiotic repo. You could just as well have have a master and an actual_master branch. Similar idiocy.

        • ScreamingFirehawk@feddit.uk
          link
          fedilink
          arrow-up
          12
          arrow-down
          1
          ·
          edit-2
          4 months ago

          It only takes one person to fuck it up. I agree it’s stupid, but introducing a conflicting standard increases the chances of someone fucking it up in the name of progressiveness. Needless to say I killed off the main branch that someone one had tried to make to replace the master branch.

        • SirQuackTheDuck@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          4 months ago

          A place I used to work at had that… The corp had rolled out a non-delete policy with something akin to *master, so when someone made a abrv_master branch it got protected and couldn’t be deleted anymore.

    • yogsototh@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      4 months ago

      I work for s company that suddenly asked to rename a lot of stuff. This had consequences. It cost time, money, and created a disconnect between internal to the dev vocabulary that couldn’t be changed easily and user facing vocabulary. Also we were lucky but this could gave broken some long used API that we are proud not to version because the policy we have internally is “we will NEVER break the API”. And so far, for 8 years we still haven’t.