unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: "Joshua M. Clulow" <josh@sysmgr.org>
Cc: Florian Weimer <fweimer@redhat.com>,
	linux-man <linux-man@vger.kernel.org>,
	libc-alpha <libc-alpha@sourceware.org>,
	Larry Dwyer <larryd.kbd@gmail.com>,
	Andrew Josey <ajosey@opengroup.org>,
	austin-group-l@opengroup.org, mtk.manpages@gmail.com,
	Elliot Hughes <enh@google.com>,
	Joseph Myers <joseph@codesourcery.com>
Subject: Re: Pseudoterminal terminology in POSIX
Date: Wed, 12 Aug 2020 15:19:00 +0200	[thread overview]
Message-ID: <20200812131900.JbiVo%steffen@sdaoden.eu> (raw)
In-Reply-To: <CAEwA5nKtyJTnQEXZZaiHywTpfDCprmupnCiq9kf5oupV7iG8RA@mail.gmail.com>

Joshua M. Clulow via austin-group-l at The Open Group wrote in
 <CAEwA5nKtyJTnQEXZZaiHywTpfDCprmupnCiq9kf5oupV7iG8RA@mail.gmail.com>:
 |On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via
 |austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
 |> On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
 |>> How about the "control" side and the "terminal" side (of the paired
 |>> device files)?
 |>
 |> Thanks for the suggestion. As far as I'm concerned, that would
 |> also be an option worth considering.
 |
 |I work on the illumos project and a few of us have been having a
 |(not yet public) discussion about this lately as well.  I think the
 |best one we could think of was:
 |
 |    the "control" side for the result of posix_openpt()
 |
 |    the "subordinate" side for the result of ptsname() and open(),

You know, (In)Subordination has a very military touch, with
exclamation mark many may have heard it.  Also in traditional
(white western world) education as such.  Like in first the
pizzle, then the bull pizzle, maybe.  So to say.  In my ears this
sounds more aggressive and weird than slave, in a technical
combination of master/slave, ever could.
Also isn't it a bit submissive here; it is under control, but
other than that.

 |    "/dev/pts" still makes sense, etc
 |
 |    we would rename our "/dev/ptmx" device file the "manager
 |    driver" rather than the "master"
 |
 |We would strongly consider using the same shift as other projects,
 |but I think only if they actually make sense; e.g., the "terminal"
 |and "pseudoterminal" end doesn't really stand out as completely
 |clear.

Manager sounds strange here, i always liked manager/worker
terminologie for threads, and used them like that (and am the
opinion that .. but that is something different and has sailed),
but for a pseudo terminal?  I think that if the standard wants to
be future proof manager should be avoided.  These guys induce
strange, ruthless and devastating decisions which destroy life on
earth (as we used to know it), so i for one do not want to be
harassed by such a term.

In accordance, maybe,
Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  reply	other threads:[~2020-08-12 13:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 11:21 Pseudoterminal terminology in POSIX Michael Kerrisk via Libc-alpha
2020-08-05 13:51 ` Steffen Nurpmeso
     [not found]   ` <20200805142049.GA17848@localhost>
2020-08-05 20:34     ` Michael Kerrisk (man-pages) via Libc-alpha
     [not found]     ` <CAP1RCkjrqKGJmh6f637D=yGuhev7ae5QJkMjv5a8iHo4X33NFw@mail.gmail.com>
     [not found]       ` <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.camel@gnu.org>
2020-08-05 20:34         ` Michael Kerrisk (man-pages) via Libc-alpha
     [not found]         ` <21048.1596645536@jinx.noi.kre.to>
     [not found]           ` <CAH7i3LrNvBo3indixGyJgS2_4F9r3cd3kOiDgPK8m-ZXj1a0zg@mail.gmail.com>
     [not found]             ` <874bfe40-5f05-151d-42b3-482baacbf0b2@gmail.com>
     [not found]               ` <CAH7i3LpXZxwaLQTY=XK8zM4jWYHSiy1feA6ZLE-mT-ZiJNak5A@mail.gmail.com>
2020-08-11  8:31                 ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-08 23:18 ` Larry Dwyer via Libc-alpha
2020-08-10 13:20   ` Joerg Schilling
2020-08-10 18:10     ` Zack Weinberg
2020-08-10 18:17       ` Samuel Thibault
2020-08-10 18:21         ` Samuel Thibault
2020-08-11  8:32       ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-10 13:58   ` Thor Lancelot Simon
2020-08-11  8:31     ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 11:51       ` Thor Lancelot Simon
2020-08-11 14:20         ` Michael Kerrisk via Libc-alpha
2020-08-12 14:37       ` Thor Lancelot Simon
2020-08-11  8:32   ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 17:29     ` Joshua M. Clulow via Libc-alpha
2020-08-12 13:19       ` Steffen Nurpmeso [this message]
2020-08-18 16:10         ` Dave Martin
2020-08-18 16:44           ` enh via Libc-alpha
2020-08-11 11:17   ` Dirk Fieldhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200812131900.JbiVo%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=ajosey@opengroup.org \
    --cc=austin-group-l@opengroup.org \
    --cc=enh@google.com \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=josh@sysmgr.org \
    --cc=larryd.kbd@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).