As of today I am supporting `main` as a git branch on all projects I touch.
Wherever possible I'll also disable `master`, but when it's not, `main` will be... the *main* branch.


Turns out that using non-historically loaded language is actually easier to understand than the current mainstream.

White/black list? Awkard, not obvious if you don't have "white: OK, black: KO" internalised.

Master/[slave|servant]? Awkward, not obvious if you aren't used to absolute, totalitarian and static power dynamics.

· · Web · 1 · 8 · 7


allow/deny list is simple, direct, descriptive.

[main|primary]/secondary is simple, direct, descriptive; and is more dynamic.
It's easy to imagine things that are "primary" in certain contexts and "secondary" in others, while "master/slave" has a hint of... immutability to it.

And this is not crazy talk, things like the amazingly good Knot DNS server struggle to explain this in their documentation:

If you replace "master" with "primary" and "slave" with "secondary", suddenly the fact that this authority is relative to each zone becomes much easier to explain (and understand).

This is a topic I've been thinking about for a long time, and what poked me to start changing this default was this:

Apparently some people find that controversial; I call it better, more readable and understandable code and documentation.

And just as a reminder: you don't have to change all the things at once, step-by-step incremental change compounds and goes a long way.

It's also fine to make mistakes and correct them, see this recent-enough example:

@evilham It's not about code readability though. And i for one think that we shouldn't allow some asshats to derail the discourse in that direction. Nor is this new or controversial. The ATA-2 standard released in '96 replaced "master/slave" with "Device 0/Device 1" and i can't remember anyone getting upset about it. As society tries to move towards more equality, open racism is making a comeback, and that's the real problem we need to push back against imho.

@tauli I totally agree. My point is that there are even tangible positive side-effects unrelated to these topics.

Which means: defending usage of those terms doesn't even have a technical argument to it, but is actively defending bigotry just for bigotry's sake.

@tauli @evilham The easiest way to push back against open racism like this is “Ju-no-ri” – just help them along, and catch them off-guard. Expose the bigotry, make them lose face. (We're fighting bigotry, not bigots; people losing bigotry is also a win condition.)

The only good reason to keep bad terminology is that it's currently in-use. Any argument to use bad terminology in new projects is flawed, and pointing that out in the right way rightly frames *them* as the ones making it “political”.

Sign in to participate in the conversation – a Fediverse instance for & by the Chaos community