Re: The request of words matter updated

Re: The request of words matter updated

[Wesley]

On 10/4/22 03:05, Daniel Shahaf wrote:
> Wesley wrote on Mon, Oct 03, 2022 at 15:27:49 +0000:
>>
>> On 9/28/22 12:34, Peter Stephenson wrote:
>>
>>> Once that's established, perhaps someone could arrange for an online vote
>>> at one of the websites that do that?  Given no technical change results
>>> from any of this, opinion is all we've got, and there's evidently no
>>> sign of a consensus.
>>
>> Do you need consensus on this change? I mean, if someone provided a
>> patch that changes master/slave to something else that makes sense
>> because they want to stay clear of those words, would it not be
>> accepted?
>
> pws posted such a patch upthread.

I read the message, but didn't see the patch below it. My bad.

>> The change is essentially a refactor and should pass all the tests..
>
> Any change has costs.  In this case, the change might shadow or unshadow
> another symbol (pws checked that for the terms his patch uses), would be
> one more manual step for any future «blame» or «log» run, would
> necessitate a rebase for anyone who has local patches to zpty.c, and
> would introduce a https://xkcd.com/927/ problem to anyone reading zsh's
> pseudo-terminal module's C source file.

That is a thing, the linux man page are still using master and slave (as
stated in 50669).

A rebase for those who have custom patches.. it is a cost that they
already have since they have forked the project.

@Sunny (OP)
How is IBM treating the Linux manual page(s), either via RHEL/SUSE or
LinuxOne?

Cheers,
Wesley

--
Wesley Schwengle

RE: Re: The request of words matter updated

[zeurkous]

On Wed, 05 Oct 2022 03:02:37 +0000, Wesley <opndev@protonmail.com> wrote:
> On 10/4/22 03:05, Daniel Shahaf wrote:
> That is a thing, the linux man page are still using master and slave (as
> stated in 50669).

As a data point: so does OpenBSD.

> @Sunny (OP)
> How is IBM treating the Linux manual page(s), either via RHEL/SUSE or
> LinuxOne?

An interesting question.

         --zeurkous.

-- 
Friggin' Machines!

Re: The request of words matter updated

[Martijn Dekker]

Op 04-10-22 om 07:29 schreef Daniel Shahaf:
> As producingoss explains, voting is going to leave half the participants
> unhappy.  Let's instead try and find a solution we can consense on.

Since there is no consensus or precedent, I propose changing "slave" to 
"minion" and keeping "master", which is the less problematic of the two 
(e.g., as far as I know, no one is objecting to the default master 
branch on millions of git repos, or to the master recordings of music 
productions).

This would minimise potential confusion while replacing the emotive, 
historically charged word by a reference to Despicable Me, which would 
inject some much needed light-heartedness into this debate.

-- 
||	modernish -- harness the shell
||	https://github.com/modernish/modernish
||
||	KornShell lives!
||	https://github.com/ksh93/ksh

Re: The request of words matter updated

[Mikael Magnusson]

On 10/8/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Tue, Oct 4, 2022 at 2:05 AM Daniel Shahaf <d.s@daniel.shahaf.name>
> wrote:
>> Wesley wrote on Mon, Oct 03, 2022 at 15:27:49 +0000:
>> > On 9/28/22 12:34, Peter Stephenson wrote:
>
>> On the other hand, the change would allegedly make it easier for some
>> people to participate in the community.
>
> I have debated this point ad nauseam.

You're certainly good at this part, maybe you should try debating by
making good points instead of trying to make your opponents sick.

> It's not good enough to say this change *might* benefit some hypothetical people[.]

The cost is 0, the gain is 0 or greater. Just do it, and someone might
be happier, nobody will be less happy.

-- 
Mikael Magnusson

Re: The request of words matter updated

[Felipe Contreras]

On Tue, Oct 4, 2022 at 2:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Wesley wrote on Mon, Oct 03, 2022 at 15:27:49 +0000:
> > On 9/28/22 12:34, Peter Stephenson wrote:

> On the other hand, the change would allegedly make it easier for some
> people to participate in the community.

I have debated this point ad nauseam. It's not good enough to say this
change *might* benefit some hypothetical people: these people have to
be identified. A lawyer cannot go to court on behalf of some
hypothetical plaintiff: somebody has to say "this affects me".

This whole "master" debate boils down to this: not **one** person has
claimed they find the term personally offensive. All the people
against the term are proposing the change on behalf of hypothetical
people, not themselves. In other words: they are being offended by
proxy.

Do we have a single black person raising their hand and saying "I find
the term 'master' personally offensive"?

-- 
Felipe Contreras

Re: The request of words matter updated

[Peter Stephenson]

> On 04/10/2022 06:29 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Let's instead try and find a solution we can consense on.

That's a noble enterprise; however, with extreme opinions around ---
by no means exclusively and I don't think typical --- we're going to
have to come to some consensus on what consensus is.

> Use whatever terms the documentation of the function we call uses for these.
...
> Let the variable names be chosen by a configure option.

I'm not really sure what these mean in practice.  The best we've got
so far seems to be to use Aix terminology, which is therefore at least
semi-standard in some context and kind of blessed by IBM at some
possible remove, "controller", "worker".  Are you suggesting there might
be some sort of partial consensus around something like that?  If not, what?

pws

Re: The request of words matter updated

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, Oct 04, 2022 at 07:05:20 +0000:
> Wesley wrote on Mon, Oct 03, 2022 at 15:27:49 +0000:
> > 
> > 
> > On 9/28/22 12:34, Peter Stephenson wrote:
> > 
> > > I'm guessing that of those who favour a change there are no major
> > > feelings in favour of any of the various alternative ways of saying "upper"
> > > and "lower"?
> > >
> > > Once that's established, perhaps someone could arrange for an online vote
> > > at one of the websites that do that?  Given no technical change results
> > > from any of this, opinion is all we've got, and there's evidently no
> > > sign of a consensus.
> > 
> > Do you need consensus on this change? I mean, if someone provided a
> > patch that changes master/slave to something else that makes sense
> > because they want to stay clear of those words, would it not be
> > accepted?
> 
> pws posted such a patch upthread.
> 
> > The change is essentially a refactor and should pass all the tests..
> > 
> 
> Any change has costs.  In this case, the change might shadow or unshadow
> another symbol (pws checked that for the terms his patch uses), would be
> one more manual step for any future «blame» or «log» run, would
> necessitate a rebase for anyone who has local patches to zpty.c, and
> would introduce a https://xkcd.com/927/ problem to anyone reading zsh's
> pseudo-terminal module's C source file.
> 
> On the other hand, the change would allegedly make it easier for some
> people to participate in the community.
> 
> On the third hand, the change would likely have social costs as well.
> However, these considerations are largely not specific to zsh, so I
> expect we could save ourselves a lot of time by finding a good write-up
> of the pros and cons of such terminology changes.  

Perhaps http://www.mit.edu/~jcb/tact.html?  It's not specific to Naming
Things, but it does touch on the question of how to interpret what other
people say.

In terms of jcb's thesis, the two positions on master/slave terminology
seem to be "tactlessness is a strict liability faux pas; if Bob opines
Alice spoke tactlessly, she should speak differently" and "Alice wasn't
being intentionally racist/speciesist/*, and Bob should follow Postel's
Law".

If I wrote the last paragraph well, I mispresented /both/ positions
equally badly :P

Daniel

> Speaking of write-ups, I wonder if producingoss would accept patches
> adding discussion of such terminology changes.
> 
> Cheers,
> 
> Daniel
> 
> > I'm not in favor of the change because there is not a technical reason
> > to solve. It is purely a policital (correctness) change. I don't see how
> > the change of master/slave in code is changing actual systematic racism
> > around the world or how it confronts former colonizing countries with
> > their often brutal past. The change itself should have minimal to no
> > impact on the code itself and should not present any problems to the
> > outside world.
> > 
> > All that said, I think IBM should be the driver of the change as it
> > doesn't comply with their "Words matter" policy. They just threw a stick
> > in a bee hive and now are watching the bees go crazy. If they want it
> > fixed, they should provide the patches to fix *their* political issue.
> > Unless someone within the zsh project really agrees with their view ofc.
> > 
> > Those are my 2 cents on this topic.
> > 
> > Cheers,
> > Wesley
> > 
> > --
> > Wesley Schwengle
> > 
> > 
> > 
> 

Re: The request of words matter updated

[Daniel Shahaf]

Wesley wrote on Mon, Oct 03, 2022 at 15:27:49 +0000:
> 
> 
> On 9/28/22 12:34, Peter Stephenson wrote:
> 
> > I'm guessing that of those who favour a change there are no major
> > feelings in favour of any of the various alternative ways of saying "upper"
> > and "lower"?
> >
> > Once that's established, perhaps someone could arrange for an online vote
> > at one of the websites that do that?  Given no technical change results
> > from any of this, opinion is all we've got, and there's evidently no
> > sign of a consensus.
> 
> Do you need consensus on this change? I mean, if someone provided a
> patch that changes master/slave to something else that makes sense
> because they want to stay clear of those words, would it not be
> accepted?

pws posted such a patch upthread.

> The change is essentially a refactor and should pass all the tests..
> 

Any change has costs.  In this case, the change might shadow or unshadow
another symbol (pws checked that for the terms his patch uses), would be
one more manual step for any future «blame» or «log» run, would
necessitate a rebase for anyone who has local patches to zpty.c, and
would introduce a https://xkcd.com/927/ problem to anyone reading zsh's
pseudo-terminal module's C source file.

On the other hand, the change would allegedly make it easier for some
people to participate in the community.

On the third hand, the change would likely have social costs as well.
However, these considerations are largely not specific to zsh, so I
expect we could save ourselves a lot of time by finding a good write-up
of the pros and cons of such terminology changes.  

Speaking of write-ups, I wonder if producingoss would accept patches
adding discussion of such terminology changes.

Cheers,

Daniel

> I'm not in favor of the change because there is not a technical reason
> to solve. It is purely a policital (correctness) change. I don't see how
> the change of master/slave in code is changing actual systematic racism
> around the world or how it confronts former colonizing countries with
> their often brutal past. The change itself should have minimal to no
> impact on the code itself and should not present any problems to the
> outside world.
> 
> All that said, I think IBM should be the driver of the change as it
> doesn't comply with their "Words matter" policy. They just threw a stick
> in a bee hive and now are watching the bees go crazy. If they want it
> fixed, they should provide the patches to fix *their* political issue.
> Unless someone within the zsh project really agrees with their view ofc.
> 
> Those are my 2 cents on this topic.
> 
> Cheers,
> Wesley
> 
> --
> Wesley Schwengle
> 
> 
> 

Re: The request of words matter updated

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, Oct 04, 2022 at 05:29:55 +0000:
> > > Once that's established, perhaps someone could arrange for an online vote
> > > at one of the websites that do that?  Given no technical change results
> > > from any of this, opinion is all we've got, and there's evidently no
> > > sign of a consensus.
> > 
> > This appears to be where we're going.  I'll do some research on this, but
> > if anyone has pointers to a good place for an anonymous vote, let me know.
> > 
> 
> I don't think it's time to vote yet; see
> <https://producingoss.com/en/consensus-democracy.html#when-to-vote>.
> 
> As producingoss explains, voting is going to leave half the participants
> unhappy.  Let's instead try and find a solution we can consense on.

I'll get the ball rolling:

- Use whatever terms the documentation of the function we call uses for
  these.  Whoever has an opinion on these terms — support, opposition,
  or anything else — is welcome to take it up with our dependencies'
  maintainers /as an individual/, but zsh /as a project/ will take no
  position on this issue, in order to facilitate collaboration between
  people who disagree on this issue.

  I mentioned this upthread, but (deliberately) not phrased it as
  a proposal at that time.

  To be clear, the proposal isn't to practise a Bystander Effect-esque
  "let someone else be the first to do something" behaviour.  The
  proposal is to name the actual parameters after the formal parameters.
  Disagreements about what to name formal parameters in zsh.git will
  remain this list's buck.  This is similar to the difference between
  a ring of N anonymous processors and a ring of N anonymous processors
  of which one is the leader.

- Let the variable names be chosen by a configure option.  (That means
  generating zpty.c from zpty.c.ac.)  The option's name, its possible
  values, and the behaviour when the option isn't passed will have to be
  decided upon.

Dnaiel

Re: The request of words matter updated

[Daniel Shahaf]

> > Once that's established, perhaps someone could arrange for an online vote
> > at one of the websites that do that?  Given no technical change results
> > from any of this, opinion is all we've got, and there's evidently no
> > sign of a consensus.
> 
> This appears to be where we're going.  I'll do some research on this, but
> if anyone has pointers to a good place for an anonymous vote, let me know.
> 

I don't think it's time to vote yet; see
<https://producingoss.com/en/consensus-democracy.html#when-to-vote>.

As producingoss explains, voting is going to leave half the participants
unhappy.  Let's instead try and find a solution we can consense on.

If we do vote, we'll have to decide who will have the right to vote;
whether the votes would be public; and what options the ballot will
have; and agree on a voting system <https://xkcd.com/1844/>.

> Thanks for the various cogent analyses of the points on both sides.
> Beyond that, I don't think anyone has been called a Nazi yet, but there's
> still time.
> 
> I think the ultimate reason this is contentious is it's something of a
> curveball (googly in my terminology; nothing to do with Mountain View,
> if anything still falls in that category) --- it brings in a whole
> heap of things not usually expected on a technical list, so all of us
> in turn bring in a whole heap of our own non-technical ideas.  At
> least, that's about the only way to rationalise an involved discussion
> on two words in a file that (as has been pointed out) most people will
> never actually read.
> 

Exactly.  The proposed patch doesn't affect generated machine code in
any way; it only affects source code and debug symbols (= it only
affects developers of zsh itself).  The arguments have nothing to do
with, say, the C execution model or forward compatibility and everything
to do with people.

[I'd link to a Wikipedia page with a list of arguments for and against
changing master/slave terminologies, but I can't find one.]

> Q&A
> ---
> 
> Q. Isn't it terrible people have such different ideas from me?
> A. You might as well complain about night being different from day.
> And actually I think it's good to have this discussion out in the 
> open rather than just closed groups of true believers.
> 
> Q. But surely my position is so obviously right it has to win by default?
> A. No, for the same reason.  There's no "obvious" at this level.  The
> fact people come to such different conclusions means it requires
> some consideration.  A vote looks to me the right way of doing this.

What wins by default is the status quo.

Cheers,

Daniel

Re: The request of words matter updated

[Wesley]

On 10/3/22 19:24, Eric Cook wrote:
> On 10/3/22 10:25, Peter Stephenson wrote:
>>
>>> Once that's established, perhaps someone could arrange for an online vote
>>> at one of the websites that do that?  Given no technical change results
>>> from any of this, opinion is all we've got, and there's evidently no
>>> sign of a consensus.
>
> based on the participants of this thread thus far:
>
> nay - wesley   - contributor

You can change my stance to neutral. I'm not for it, but as stated in my
  e-mail I think IBM should drive the change (supply the patches) if
they want the change to happen.

Cheers,
Wesley

--
Wesley Schwengle

Re: The request of words matter updated

[Eric Cook]

On 10/3/22 10:25, Peter Stephenson wrote:
>
>> Once that's established, perhaps someone could arrange for an online vote
>> at one of the websites that do that?  Given no technical change results
>> from any of this, opinion is all we've got, and there's evidently no
>> sign of a consensus.

based on the participants of this thread thus far:

neutral - mikael  - contributor w/commitbit
neutral - eric    - contributor w/commitbit
neutral - ellenor - mailing list denizen
yay - bart     - core contributor
yay - peter    - core contributor
yay - lawrence - contributor
yay - clinton  - mailing list denizen
yay - IBM      - requester
nay - daniel   - core(?) contributor
nay - zeurkous - contributor
nay - felipe   - contributor
nay - wesley   - contributor
nay - axel     - contributor

Re: The request of words matter updated

[Wesley]

On 9/28/22 12:34, Peter Stephenson wrote:

> I'm guessing that of those who favour a change there are no major
> feelings in favour of any of the various alternative ways of saying "upper"
> and "lower"?
>
> Once that's established, perhaps someone could arrange for an online vote
> at one of the websites that do that?  Given no technical change results
> from any of this, opinion is all we've got, and there's evidently no
> sign of a consensus.

Do you need consensus on this change? I mean, if someone provided a
patch that changes master/slave to something else that makes sense
because they want to stay clear of those words, would it not be
accepted? The change is essentially a refactor and should pass all the
tests..

I'm not in favor of the change because there is not a technical reason
to solve. It is purely a policital (correctness) change. I don't see how
the change of master/slave in code is changing actual systematic racism
around the world or how it confronts former colonizing countries with
their often brutal past. The change itself should have minimal to no
impact on the code itself and should not present any problems to the
outside world.

All that said, I think IBM should be the driver of the change as it
doesn't comply with their "Words matter" policy. They just threw a stick
in a bee hive and now are watching the bees go crazy. If they want it
fixed, they should provide the patches to fix *their* political issue.
Unless someone within the zsh project really agrees with their view ofc.

Those are my 2 cents on this topic.

Cheers,
Wesley

--
Wesley Schwengle

Re: The request of words matter updated

[Peter Stephenson]

> On 01/10/2022 05:40 Lawrence Velázquez <larryv@zsh.org> wrote:
> On Mon, Sep 26, 2022, at 11:15 PM, Lawrence Velázquez wrote:
> > AIX uses "controller" and "worker"
> > (https://www.ibm.com/docs/en/aix/7.3?topic=files-pty-special-file).

I realise this is a week old now, but in the light of Bart's
points, using AIX terminology would be poetic justice, and it's
also satisfyingly similar to faculty / student (which, though
amusing, would be way too mystifying).

pws

Re: The request of words matter updated

[Peter Stephenson]

> On 28/09/2022 17:34 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> As Lawrence and Bart already noted, there's no good steer here from the
> various technical documents, or even vendors' manual pages.

Lawrence has some new input here, I'll keep that separate.

> Once that's established, perhaps someone could arrange for an online vote
> at one of the websites that do that?  Given no technical change results
> from any of this, opinion is all we've got, and there's evidently no
> sign of a consensus.

This appears to be where we're going.  I'll do some research on this, but
if anyone has pointers to a good place for an anonymous vote, let me know.

Thanks for the various cogent analyses of the points on both sides.
Beyond that, I don't think anyone has been called a Nazi yet, but there's
still time.

I think the ultimate reason this is contentious is it's something of a
curveball (googly in my terminology; nothing to do with Mountain View,
if anything still falls in that category) --- it brings in a whole
heap of things not usually expected on a technical list, so all of us
in turn bring in a whole heap of our own non-technical ideas.  At
least, that's about the only way to rationalise an involved discussion
on two words in a file that (as has been pointed out) most people will
never actually read.

Q&A
---

Q. Isn't it terrible people have such different ideas from me?
A. You might as well complain about night being different from day.
And actually I think it's good to have this discussion out in the 
open rather than just closed groups of true believers.

Q. But surely my position is so obviously right it has to win by default?
A. No, for the same reason.  There's no "obvious" at this level.  The
fact people come to such different conclusions means it requires
some consideration.  A vote looks to me the right way of doing this.

pws

Re: The request of words matter updated

[Lawrence Velázquez]

On Mon, Sep 26, 2022, at 11:15 PM, Lawrence Velázquez wrote:
> On Mon, Sep 19, 2022, at 2:20 PM, Bart Schaefer wrote:
>> but at the present time the Linux documentation for pty(7),
>> openpty(3), etc., still use the terms in question.  (I haven't
>> checked other platforms.)
>
> FreeBSD, NetBSD, and OpenBSD do as well.
>
> Illumos uses "manager" and "subsidiary" (https://illumos.org/man/4D/pty).
>
> AIX uses "controller" and "worker"
> (https://www.ibm.com/docs/en/aix/7.3?topic=files-pty-special-file).

MacOS 12.6 uses "primary" and "replica".

Solaris 11.4 splits the difference with "controller" and "slave",
which strikes me as a lateral move at best.  A for effort, I suppose.

(No URLs, unfortunately, as I checked live systems.)

-- 
vq

Re: The request of words matter updated

[Axel Beckert]

Hi,

On Tue, Sep 27, 2022 at 11:32:03PM +0200, Mikael Magnusson wrote:
> On 9/27/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > -1 on the patch because I don't believe people who disagree with the
> > change feel comfortable saying so publicly.
> 
> If a word is so bad that people don't want to say that they want to
> keep it, then we should not keep it.

IMHO it's the opposite way: If a change causes people to stay silent
because they fear a hate campaign if they say that they don't like
such a change, then that change shouldn't be done alone for that.

		Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

Re: The request of words matter updated

[Axel Beckert]

Hi,

On Tue, Sep 27, 2022 at 08:54:46PM +0000, Daniel Shahaf wrote:
> -1 on the patch because I don't believe people who disagree with the
> change feel comfortable saying so publicly.

Full Ack.

Actually I see no reason to change _non-surfacing_ variables at all.

		Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

Re: The request of words matter updated

[Lawrence Velázquez]

On Wed, Sep 28, 2022, at 2:30 AM, Ellenor Bjornsdottir wrote:
> Will this change actually harm anything - foreign libraries, etc?

As far as I can tell, no.  The renamed variables are function-local.

-- 
vq

Re: The request of words matter updated

[Lawrence Velázquez]

On Wed, Sep 28, 2022, at 4:01 PM, Eric Cook wrote:
> 2) not even zpty's documentation in zshmodules(1) refers to the existing terms.

I thought so too, but it turns out there is a single instance.  I'm
actually surprised there aren't more.

> 4) It's not similar to changing the default branch in zsh's vcs repo or
>     changing listmaster@zsh.org, faqmaster@zsh.org in any way. if the 
> change happens
>     within a week it will be forgotten again, if even noticed.

Yup.  As far as I can tell -- and as Chen Xiao Ling noted in their
original message -- nothing we've been discussing is externally
visible (other than the aforementioned bit of documentation).

>     zpty isn't commonly used from what i can tell, i imagine people 
> looking at its source code
>     are even fewer.

If cosmic rays were to spontaneously apply Peter's patch, it would
take literally years for anyone to notice.

https://sourceforge.net/p/zsh/code/ci/master/log/?path=/Src/Modules/zpty.c

-- 
vq

Re: The request of words matter updated

[Eric Cook]

On 9/27/22 04:44, Peter Stephenson wrote:
>
>> On 27/09/2022 05:22 Bart Schaefer <schaefer@brasslantern.com> wrote:
>>
>>
>> On Mon, Sep 26, 2022 at 8:18 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>>>
>>> Illumos uses "manager" and "subsidiary"
>>> AIX uses "controller" and "worker"
>>
>> Well, that's no fun.  It means there's no "term of art" we can adopt.
>> On the other hand, I guess, it means we don't have to worry about
>> confusing future programmers, because they'll already be confused.
>
> My only comment is that if we pick something unique and do the job
> properly this time, then any further update to fit in with standards
> is a 30 second automatic replacement.  So I don't think it's worth
> agonising over.
>
>> In this particular context I'd probably choose something like
>> superior/inferior ... neither subsidiary nor worker really fits what
>> that half of the PTY pair is doing, IMO.  They sound like words chosen
>> for a global search-and-replace over a codebase nobody was willing to
>> actually read.
>
> So e.g. zsuperior and zinferior would give us that ability (but you may
> well be right superior and inferior are good enough --- replacing
> master and slave didn't hit any clashes).
>
> pws
>


Indifference to the change in general

1) wasn't aware of the their existence until this thread.
    which did seem weird, like some automated search happened to find them.

2) not even zpty's documentation in zshmodules(1) refers to the existing terms.

3) as pointed out by Lawrence, the terms aren't even consistency used among operating systems
    so the feigned confusion of these internal variables already exists.

4) It's not similar to changing the default branch in zsh's vcs repo or
    changing listmaster@zsh.org, faqmaster@zsh.org in any way. if the change happens
    within a week it will be forgotten again, if even noticed.
    zpty isn't commonly used from what i can tell, i imagine people looking at its source code
    are even fewer.

Re: The request of words matter updated

[Peter Stephenson]

On 27/09/2022 21:54 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> I will also point out that tracking the terms used by the formal parameters
> in the callee's header files or documentation, as proposed upthread — is
> a clear, objective criterion; makes the terminology decisions Someone
> Else's Problem; makes the code easier to read; and involves less churn.
> Without advocating for that particular solution or considering what
> downsides it may have, I do wish to say those properties thereof seem
> desirable.

As Lawrence and Bart already noted, there's no good steer here from the
various technical documents, or even vendors' manual pages.  The only
hint in this direction might be to use ptm and pts, which doesn't seem
very elegant or likely to achieve any kind of consensus, so I won't
propose it.

I'm guessing that of those who favour a change there are no major
feelings in favour of any of the various alternative ways of saying "upper"
and "lower"?

Once that's established, perhaps someone could arrange for an online vote
at one of the websites that do that?  Given no technical change results
from any of this, opinion is all we've got, and there's evidently no
sign of a consensus.

Cheers
pws

Re: The request of words matter updated

[Clinton Bunch]

On 9/28/2022 1:14 AM, Felipe Contreras wrote:
> On Tue, Sep 27, 2022 at 4:00 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> -1 on the patch because I don't believe people who disagree with the
>> change feel comfortable saying so publicly.
> Agreed. I am one of the few people comfortable with disagreeing to
> such changes publicly:
>
> https://felipec.wordpress.com/2020/11/13/git-master/
>
> Plenty of people have sent me private words of encouragement stating
> this master/slave terminology change is nonsense, but they don't dare
> to say so publicly.
>
> Just because the silent majority is silent doesn't mean it doesn't exist.
>
Because they're silent, there is no way to tell if they are a majority.  
Personally, I think the silence comes from the fact 90-95% of people 
just don't care.


These words cause some people pain.  You may think the source of that 
pain is silly, but it doesn't make the pain any less real. (Ask anyone 
who's been clinically depressed about feeling pain other people tell you 
you shouldn't feel)

It's a small change that alleviates pain.  That should be reason enough 
to do it.

Re: The request of words matter updated

[Ellenor Bjornsdottir]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Will this change actually harm anything - foreign libraries, etc?

If not, then because it clearly benefits some people, the cost-benefit calculus favors change.

I don't like it, but my opinion doesn't matter because the change harms nothing.

On 28 September 2022 06:17:59 UTC, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>On Tue, Sep 27, 2022 at 4:39 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> On 9/27/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> > -1 on the patch because I don't believe people who disagree with the
>> > change feel comfortable saying so publicly.
>>
>> If a word is so bad that people don't want to say that they want to
>> keep it, then we should not keep it.
>
>There's nothing "bad" about the word a priori. If *you* believe it has
>to be changed, then *you* have the burden of proof.
>
>Just like any other change.
>
>-- 
>Felipe Contreras
>

-- 
Ellenor Bjornsdottir (she)
sysadmin umbrellix.net

[-- Attachment #2: Type: text/html, Size: 1637 bytes --]

Re: The request of words matter updated

[Felipe Contreras]

On Tue, Sep 27, 2022 at 4:39 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 9/27/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > -1 on the patch because I don't believe people who disagree with the
> > change feel comfortable saying so publicly.
>
> If a word is so bad that people don't want to say that they want to
> keep it, then we should not keep it.

There's nothing "bad" about the word a priori. If *you* believe it has
to be changed, then *you* have the burden of proof.

Just like any other change.

-- 
Felipe Contreras

Re: The request of words matter updated

[Felipe Contreras]

On Tue, Sep 27, 2022 at 4:00 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> -1 on the patch because I don't believe people who disagree with the
> change feel comfortable saying so publicly.

Agreed. I am one of the few people comfortable with disagreeing to
such changes publicly:

https://felipec.wordpress.com/2020/11/13/git-master/

Plenty of people have sent me private words of encouragement stating
this master/slave terminology change is nonsense, but they don't dare
to say so publicly.

Just because the silent majority is silent doesn't mean it doesn't exist.

-- 
Felipe Contreras

Re: The request of words matter updated

[Mikael Magnusson]

On 9/27/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> -1 on the patch because I don't believe people who disagree with the
> change feel comfortable saying so publicly.

If a word is so bad that people don't want to say that they want to
keep it, then we should not keep it.

-- 
Mikael Magnusson

Re: The request of words matter updated

[Clinton Bunch]

On 9/27/2022 4:15 PM, Clinton Bunch wrote:
> On 9/27/2022 3:54 PM, Daniel Shahaf wrote:
>> -1 on the patch because I don't believe people who disagree with the
>> change feel comfortable saying so publicly.
>>
>> I will also point out that tracking the terms used by the formal 
>> parameters
>> in the callee's header files or documentation, as proposed upthread — is
>> a clear, objective criterion; makes the terminology decisions Someone
>> Else's Problem; makes the code easier to read; and involves less churn.
>> Without advocating for that particular solution or considering what
>> downsides it may have, I do wish to say those properties thereof seem
>> desirable.
>>
> We've been trying to rid ourselves of these words for twenty years in 
> the IT industry.  They were used because they accurately describe the 
> relationship and at the dawn of Unix and the Internet, the emotional 
> charge the words carry wasn't recognized.
>
>
> For PTYs  I like the terms controller and subsidiary.  It seems to 
> describe the relationship better than other suggestions.  The use of 
> superior and inferior as otherwhere suggested strike me as eventually 
> running into the same problem of being emotionally charged.
>
I will also point out that making it "Somebody Else's Problem" Is a big 
part of why we haven't successfully rid ourselves of these terms in over 
two decades of realizing they were problematic. Let's not perpetuate the 
problem.

Re: The request of words matter updated

[Clinton Bunch]

On 9/27/2022 3:54 PM, Daniel Shahaf wrote:
> -1 on the patch because I don't believe people who disagree with the
> change feel comfortable saying so publicly.
>
> I will also point out that tracking the terms used by the formal parameters
> in the callee's header files or documentation, as proposed upthread — is
> a clear, objective criterion; makes the terminology decisions Someone
> Else's Problem; makes the code easier to read; and involves less churn.
> Without advocating for that particular solution or considering what
> downsides it may have, I do wish to say those properties thereof seem
> desirable.
>
We've been trying to rid ourselves of these words for twenty years in 
the IT industry.  They were used because they accurately describe the 
relationship and at the dawn of Unix and the Internet, the emotional 
charge the words carry wasn't recognized.


For PTYs  I like the terms controller and subsidiary.  It seems to 
describe the relationship better than other suggestions.  The use of 
superior and inferior as otherwhere suggested strike me as eventually 
running into the same problem of being emotionally charged.

Re: The request of words matter updated

[Daniel Shahaf]

-1 on the patch because I don't believe people who disagree with the
change feel comfortable saying so publicly.

I will also point out that tracking the terms used by the formal parameters
in the callee's header files or documentation, as proposed upthread — is
a clear, objective criterion; makes the terminology decisions Someone
Else's Problem; makes the code easier to read; and involves less churn.
Without advocating for that particular solution or considering what
downsides it may have, I do wish to say those properties thereof seem
desirable.

Re: The request of words matter updated

[Peter Stephenson]

> On 27/09/2022 05:22 Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
>  
> On Mon, Sep 26, 2022 at 8:18 PM Lawrence Velázquez <larryv@zsh.org> wrote:
> >
> > Illumos uses "manager" and "subsidiary"
> > AIX uses "controller" and "worker"
> 
> Well, that's no fun.  It means there's no "term of art" we can adopt.
> On the other hand, I guess, it means we don't have to worry about
> confusing future programmers, because they'll already be confused.

My only comment is that if we pick something unique and do the job
properly this time, then any further update to fit in with standards
is a 30 second automatic replacement.  So I don't think it's worth
agonising over.

> In this particular context I'd probably choose something like
> superior/inferior ... neither subsidiary nor worker really fits what
> that half of the PTY pair is doing, IMO.  They sound like words chosen
> for a global search-and-replace over a codebase nobody was willing to
> actually read.

So e.g. zsuperior and zinferior would give us that ability (but you may
well be right superior and inferior are good enough --- replacing
master and slave didn't hit any clashes).

pws

diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index dfd2a2a7a..b9e3b4050 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -188,7 +188,7 @@ getptycmd(char *name)
 #endif
 
 static int
-get_pty(int master, int *retfd)
+get_pty(int zsuperior, int *retfd)
 {
     static char *name;
     static int mfd, sfd;
@@ -196,7 +196,7 @@ get_pty(int master, int *retfd)
     int ret;
 #endif
 
-    if (master) {
+    if (zsuperior) {
 #ifdef HAVE_POSIX_OPENPT
 	if ((mfd = posix_openpt(O_RDWR|O_NOCTTY)) < 0)
 #else
@@ -252,7 +252,7 @@ get_pty(int master, int *retfd)
 #else /* No /dev/ptmx or no pt functions */
 
 static int
-get_pty(int master, int *retfd)
+get_pty(int zsuperior, int *retfd)
 {
 
 #ifdef __linux
@@ -275,7 +275,7 @@ get_pty(int master, int *retfd)
     static int mfd, sfd;
     char *p1, *p2;
 
-    if (master) {
+    if (zsuperior) {
 	strcpy(name, "/dev/ptyxx");
 #if defined(__BEOS__) || defined(__HAIKU__)
 	name[7] = '/';
@@ -310,7 +310,7 @@ static int
 newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 {
     Ptycmd p;
-    int master, slave, pid, oineval = ineval, ret;
+    int zsuperior, zinferior, pid, oineval = ineval, ret;
     char *oscriptname = scriptname, syncch;
     Eprog prog;
 
@@ -327,7 +327,7 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 	return 1;
     }
 
-    if (get_pty(1, &master)) {
+    if (get_pty(1, &zsuperior)) {
 	zwarnnam(nam, "can't open pseudo terminal: %e", errno);
 	scriptname = oscriptname;
 	ineval = oineval;
@@ -335,7 +335,7 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
     }
     if ((pid = fork()) == -1) {
 	zwarnnam(nam, "can't create pty command %s: %e", pname, errno);
-	close(master);
+	close(zsuperior);
 	scriptname = oscriptname;
 	ineval = oineval;
 	return 1;
@@ -360,9 +360,9 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 	}
 #endif
 
-	if (get_pty(0, &slave))
+	if (get_pty(0, &zinferior))
 	    exit(1);
-	SHTTY = slave;
+	SHTTY = zinferior;
 	attachtty(mypid);
 #ifdef TIOCGWINSZ
 	/* Set the window size before associating with the terminal *
@@ -370,10 +370,10 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 	if (interact) {
 	    struct ttyinfo info;
 
-	    if (ioctl(slave, TIOCGWINSZ, (char *) &info.winsize) == 0) {
+	    if (ioctl(zinferior, TIOCGWINSZ, (char *) &info.winsize) == 0) {
 		info.winsize.ws_row = zterm_lines;
 		info.winsize.ws_col = zterm_columns;
-		ioctl(slave, TIOCSWINSZ, (char *) &info.winsize);
+		ioctl(zinferior, TIOCSWINSZ, (char *) &info.winsize);
 	    }
 	}
 #endif /* TIOCGWINSZ */
@@ -381,7 +381,7 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 	if (!echo) {
 	    struct ttyinfo info;
 
-	    if (!ptygettyinfo(slave, &info)) {
+	    if (!ptygettyinfo(zinferior, &info)) {
 #ifdef HAVE_TERMIOS_H
 		info.tio.c_lflag &= ~ECHO;
 #else
@@ -391,25 +391,25 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 		info.tio.lmodes &= ~ECHO; /**** dunno if this is right */
 #endif
 #endif
-		ptysettyinfo(slave, &info);
+		ptysettyinfo(zinferior, &info);
 	    }
 	}
 
 #ifdef TIOCSCTTY
-	ioctl(slave, TIOCSCTTY, 0);
+	ioctl(zinferior, TIOCSCTTY, 0);
 #endif
 
 	close(0);
 	close(1);
 	close(2);
 
-	dup2(slave, 0);
-	dup2(slave, 1);
-	dup2(slave, 2);
+	dup2(zinferior, 0);
+	dup2(zinferior, 1);
+	dup2(zinferior, 2);
 
 	closem(FDT_UNUSED, 0);
-	close(slave);
-	close(master);
+	close(zinferior);
+	close(zsuperior);
 	close(coprocin);
 	close(coprocout);
 	init_io(NULL);
@@ -436,22 +436,22 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 	zexit(lastval, ZEXIT_NORMAL);
     }
 #ifndef USE_CYGWIN_FIX
-    master = movefd(master);
-    if (master == -1) {
-	zerrnam(nam, "cannot duplicate fd %d: %e", master, errno);
+    zsuperior = movefd(zsuperior);
+    if (zsuperior == -1) {
+	zerrnam(nam, "cannot duplicate fd %d: %e", zsuperior, errno);
 	scriptname = oscriptname;
 	ineval = oineval;
 	return 1;
     }
 #else
-    addmodulefd(master, FDT_INTERNAL);
+    addmodulefd(zsuperior, FDT_INTERNAL);
 #endif
 
     p = (Ptycmd) zalloc(sizeof(*p));
 
     p->name = ztrdup(pname);
     p->args = zarrdup(args);
-    p->fd = master;
+    p->fd = zsuperior;
     p->pid = pid;
     p->echo = echo;
     p->nblock = nblock;
@@ -464,13 +464,13 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
     ptycmds = p;
 
     if (nblock)
-	ptynonblock(master);
+	ptynonblock(zsuperior);
 
     scriptname = oscriptname;
     ineval = oineval;
 
     do {
-	ret = read(master, &syncch, 1);
+	ret = read(zsuperior, &syncch, 1);
     } while (ret != 1 && (
 #ifdef EWOULDBLOCK
 	    errno == EWOULDBLOCK ||
@@ -481,7 +481,7 @@ newptycmd(char *nam, char *pname, char **args, int echo, int nblock)
 #endif
 	    errno == EINTR));
 
-    setiparam_no_convert("REPLY", (zlong)master);
+    setiparam_no_convert("REPLY", (zlong)zsuperior);
 
     return 0;
 }

Re: The request of words matter updated

[Bart Schaefer]

On Mon, Sep 26, 2022 at 8:18 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> Illumos uses "manager" and "subsidiary"
> AIX uses "controller" and "worker"

Well, that's no fun.  It means there's no "term of art" we can adopt.
On the other hand, I guess, it means we don't have to worry about
confusing future programmers, because they'll already be confused.

> On Mon, Sep 19, 2022, at 2:20 PM, Bart Schaefer wrote:
> > Should we plan for this change to track the library terminology?
>
> Are Linux or the BSDs planning on making similar changes?

I'm sure they're at least aware of the general trend toward
eliminating this sort of terminology, I've been seeing it discussed in
other contexts for more than a decade.

In this particular context I'd probably choose something like
superior/inferior ... neither subsidiary nor worker really fits what
that half of the PTY pair is doing, IMO.  They sound like words chosen
for a global search-and-replace over a codebase nobody was willing to
actually read.

Re: The request of words matter updated

[Lawrence Velázquez]

On Mon, Sep 19, 2022, at 2:20 PM, Bart Schaefer wrote:
> On Sun, Sep 18, 2022 at 11:58 PM Xiao Ling XL Chen <chenxlxl@cn.ibm.com> wrote:
>>
>> ... as what the words matter requirement, may I ask change them in a future level?
>
> I support this effort in general

+1

> but at the present time the Linux documentation for pty(7),
> openpty(3), etc., still use the terms in question.  (I haven't
> checked other platforms.)

FreeBSD, NetBSD, and OpenBSD do as well.

Illumos uses "manager" and "subsidiary" (https://illumos.org/man/4D/pty).

AIX uses "controller" and "worker"
(https://www.ibm.com/docs/en/aix/7.3?topic=files-pty-special-file).

> Should we plan for this change to track the library terminology?

Are Linux or the BSDs planning on making similar changes?  If not,
we could be waiting for a very long time.

-- 
vq

Re: The request of words matter updated

[Bart Schaefer]

On Sun, Sep 18, 2022 at 11:58 PM Xiao Ling XL Chen <chenxlxl@cn.ibm.com> wrote:
>
> ... as what the words matter requirement, may I ask change them in a future level?

I support this effort in general, but at the present time the Linux
documentation for pty(7), openpty(3), etc., still use the terms in
question.  (I haven't checked other platforms.)  Should we plan for
this change to track the library terminology?

The request of words matter updated

[Xiao Ling XL Chen]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

There 12 slave and 16 master used as variables in source code   "Src/Modules/zpty.c". Even though the words "slave" & "master" are used as internal static variables, and not be exposed to external calling or exported it in message, as what the words matter requirement, may I ask change them in a future level? For example, replace “slave” with "worker", "child", "helper", "replica", "follower", or "secondary [server, node, process, or other noun]", and replace “master” with "controller", "leader", "manager", "main", "coordinator", "parent", or "primary [server, node, process, or other noun]". Thanks.

Take care, stay strong, and stay safe.

Best regards,
Sunny (Xiao Ling Chen, 陈小玲)

z/OS USS SU&DBX Development and L3
IBM China Systems & Technology Lab (CSTL)
Tel:    86-010-82452454
E-mail: chenxlxl@cn.ibm.com<mailto:chenxlxl@cn.ibm.com>
--



[-- Attachment #2: Type: text/html, Size: 4093 bytes --]