While the Linux kernel has inclusive terminology guidelines for the past five years to replace phrases like master/slave and blacklist/whitelist, there has surprisingly been a “genocide” function within the kernel that was questioned when it was first submitted for inclusion but now removed in Linux 6.19.
Introduced to the Linux kernel back in 2023 was the d_genocide() function as part of various dcache updates to the kernel. The genocide name was questioned when the patches were first posted by longtime Linux developer Al Viro
I wouldn’t mind replacing ‘kill’ with some variant of send/signal, sure that’s what kill does.
end?
That one does what it says, says what it does, is short to type, and doesn’t psychologically reinforce any negative stereotypes.
like unalive? fuck this generation.
“Unalive” isn’t being used for political correctness, it is being used because algorithms actively penalize content using the words “kill” and “suicide”, so using “unalive” instead is a way to work around censorship.
I just want the tin to match what’s inside
Not sure what that means: the function & signal are both named kill & the name
signalis already taken. However, that’s a fairer position.It does lead to some interesting sentences when combined with other kernel terms:
Sure, just break millions of other people’s scripts on a whim.
That’s a false choice. And kind of silly. If you read the article, Linux has already changed commands somehow without blowing up everyone’s scripts.
The article is about an internal kernel API: They can easily rename those, since they are not exposed to user-space.
But you seem to be talking about the
killcommand and/or thekillfunction, that are part of the POSIX and C standards, respectively. Renaming either would break a shit-ton of code, unless you merely aliased them. And while I agree thatkillis a poor name, adding non-standard aliases doesn’t really offer much benefit