Linux Sound Subsystem Begins Cleaning Up Its Terminology To Meet Inclusive Guidelines

[Djhg2000]

Linus would go well out of his way to make someone's day shitty. They didn't "go after him", he himself made an effort to be more flexible in his wording since it was divisive. People did complain about the non-PC stuff he said but it was sometimes justified in my opinion. Especially when he would insult specific people without regard for professional criticism or discourse. It was actually not very productive or effective.

Richard Stallman, however, got screwed in all regards. Dude isn't even non-PC and still manages to be a very honest spirit.

Anyways, I'm mentioning that since the cases are definitely different and it's dangerous to lob things together in a generic way like that. They need to be differentiated.

RMS isn't non-PC? Have you listened to him? It's barely even possible for him to care less about what politicians want, and he's hardly sparse with his words when he disagrees about something anyway.

The only major difference is that Torvalds went on a more personal level, but it's really not relevant. The end goal was as always to remove influence from principled people which didn't agree with the PC narrative. Then they swoop in with "solutions" like CoCs and want everyone to play ball unless they want to get screwed.

Then again I think Torvalds should've kept going with his offensive strategy. Kernel development is serious business, Linux has worked its way into critical systems all over the world because it's stable and brings a lot of functionality along with it. If we don't have a hard stance on bad code and discourage it into oblivion then it's only a matter of time before we get overwhelmed with code of less than stellar quality and something dangerous slips between the cracks. Bad code submissions to Linux are rewarded with expletives and insults because they should be.

[computerquip]

RMS isn't non-PC? Have you listened to him? It's barely even possible for him to care less about what politicians want, and he's hardly sparse with his words when he disagrees about something anyway.

The only major difference is that Torvalds went on a more personal level, but it's really not relevant. The end goal was as always to remove influence from principled people which didn't agree with the PC narrative. Then they swoop in with "solutions" like CoCs and want everyone to play ball unless they want to get screwed.

Then again I think Torvalds should've kept going with his offensive strategy. Kernel development is serious business, Linux has worked its way into critical systems all over the world because it's stable and brings a lot of functionality along with it. If we don't have a hard stance on bad code and discourage it into oblivion then it's only a matter of time before we get overwhelmed with code of less than stellar quality and something dangerous slips between the cracks. Bad code submissions to Linux are rewarded with expletives and insults because they should be.

Then you're the problem. Linus telling someone to shut the fuck up over their opinion is one thing, telling them why their opinion is bad without insulting them is another. You do not need to call someone garbage or say they're an idiot in order to point out their mistakes so they can fix them. The fact you don't realize that is the whole problem.

[Djhg2000]

Then you're the problem. Linus telling someone to shut the fuck up over their opinion is one thing, telling them why their opinion is bad without insulting them is another. You do not need to call someone garbage or say they're an idiot in order to point out their mistakes so they can fix them. The fact you don't realize that is the whole problem.

What code does isn't a matter of opinion. Neither the compiler nor the processor gives a shit about what your opinions are.

But you don't seem to realize the gravity of the issue here. This is kernel code. This is code which is mission critical to a staggering number of devices. In some cases misbehaving kernels can be literally fatal. Crashes are obvious enough and can be somewhat safeguarded against with hardware like safe passive states and watchdogs, but memory corruption is a different beast we must avoid at all cost.

If the only punishment for submitting bad code is pointers on where to fix it then the author is just going to do it again. Even worse let their guard down because any errors will get pointed out anyways. We absolutely do not want this to happen!


If on the other hand they're publicly shamed for submitting bad code, which is a public process so you can't get hung up on that either, you can bet your ass they're going to tripple check their code twice to make sure they get it right before submitting a follow up.

It may seem harsh to you but tough shit, kernel development isn't the same playground sandpit as some random Python script on GitHub where you can just throw stuff together by trial and error.

You either deal with the risks and do your job properly or you stay away from kernel development. It's like being a deep sea welder and complaining about having to wear protective lenses.

[computerquip]

If on the other hand they're publicly shamed for submitting bad code, which is a public process so you can't get hung up on that either, you can bet your ass they're going to tripple check their code twice to make sure they get it right before submitting a follow up.

No, you can bet your ass they'll just decide not contribute anymore and/or be vengeful about being insulted. You should put yourself in the shoes of some of the people who have been straight up abused by Linus. Imagine putting work into something for days to weeks just for him to skim over it and call you and your code garbage without any real decent explanation. I've quit at least one job over similar behavior myself. Developers aren't fucking slaves, they don't have to take anyone's abuse and they shouldn't.

What code does isn't a matter of opinion. Neither the compiler nor the processor gives a shit about what your opinions are.

Code itself isn't subjective, but what code *should* do is. Design in general is a very controversial topic, let alone software design.

[Djhg2000]

No, you can bet your ass they'll just decide not contribute anymore and/or be vengeful about being insulted. You should put yourself in the shoes of some of the people who have been straight up abused by Linus. Imagine putting work into something for days to weeks just for him to skim over it and call you and your code garbage without any real decent explanation. I've quit at least one job over similar behavior myself. Developers aren't fucking slaves, they don't have to take anyone's abuse and they shouldn't.

Then congratulations, kernel development isn't for you. Bad code in such a critical component is met with justifiable backlash. If you want to stay on top then you better be prepared to work hard to be the best of the best. This isn't some grade school sporting event where everyone gets a participation medal. Kernel development isn't for everyone and it shouldn't be. Some people are simply better suited to developing applications running on top of the kernel, where you have an operating system to somewhat protect you from errors and you can design it however you want.

Also if you think this is abuse and human slavery (a term which people keep diminishing further and further by using it improperly) then you haven't had a particularly rough life, but you keep pretending to miss the point. This is kernel development. What's more important, your feelings or human lives? Because as I said before, there are some cases where Linux is handling critical functions where memory corruption could actually be fatal.

Not figuratively, it's literally human lives at stake. You have companies like Airbus and Boeing using Linux, how do you think they'll react if the kernel started having memory corruption? They wouldn't say "oh the poor feelings of that one software developer", they would trace the error back to the commit and pull request, see the discussion and throw Linux out head first in favor of some other kernel if Torvalds just let errors slide to not hurt their feelings. You may not take kernel development seriously but thankfully Torvalds does.

Code itself isn't subjective, but what code *should* do is. Design in general is a very controversial topic, let alone software design.

So what? Does that suddenly make bad code acceptable in a kernel? Again this isn't some random python script, this is the very foundation for your operating system! You have no protections between your code and the processor. On top of that the code must play nice with other code, be stable, be secure because hackers will look at it with a microscope if they have to, actually do what it's supposed to and be reasonably performant as well.

[oiaohm]

Some of the clean up in terms does make sense. blacklist/whitelist to denylist/allowlist and blocklist/passlist does make sense not from a inclusive language point of view but basic interpenetration error prevention. Lot of people you ask them to describe what a blacklist is and what whitelist is and you get a blank impression or the wrong answer. Ask them what a blocklist/passlist or a denylist/allowlist is they get right first time. So some of these change will lower the learning curve to those starting out with kernel development.

Something to remember if you are coming from an accountancy background in the black is good. In the red or white is bad. So to some people blacklist and whitelist meaning can be totally inverted to what the computer world expects. Its just like the fun of teaching a accountancy person computer stuff for the first time and the have the hard logic that default=bad as you must avoid default on payments.

Djhg2000 you are right lives can be on the line if people miss read these terms and set stuff wrong. If changing these terms equal less possibility of reading them wrong this will be good.

Master/slave I am not exactly sure on but there will be a lot of places where those terms have been used in the kernel that really don't describe what is in fact going on.

I really wish we did not have to wait for inclusive language crap to look at these terms and ask are they right to have the most number of people read them and understand what in heck is going on.

[computerquip]

Imagine being this fragile...

You'll eventually wash out of the industry and no one will miss you. Just quality control at work.

Realize for a second you're essentially saying I'm fragile for wanting to be treated as human. That's really not a precedent you want to set.

[Djhg2000]

Some of the clean up in terms does make sense. blacklist/whitelist to denylist/allowlist and blocklist/passlist does make sense not from a inclusive language point of view but basic interpenetration error prevention. Lot of people you ask them to describe what a blacklist is and what whitelist is and you get a blank impression or the wrong answer. Ask them what a blocklist/passlist or a denylist/allowlist is they get right first time. So some of these change will lower the learning curve to those starting out with kernel development.

Something to remember if you are coming from an accountancy background in the black is good. In the red or white is bad. So to some people blacklist and whitelist meaning can be totally inverted to what the computer world expects. Its just like the fun of teaching a accountancy person computer stuff for the first time and the have the hard logic that default=bad as you must avoid default on payments.

Djhg2000 you are right lives can be on the line if people miss read these terms and set stuff wrong. If changing these terms equal less possibility of reading them wrong this will be good.

Master/slave I am not exactly sure on but there will be a lot of places where those terms have been used in the kernel that really don't describe what is in fact going on.

I really wish we did not have to wait for inclusive language crap to look at these terms and ask are they right to have the most number of people read them and understand what in heck is going on.

I've never heard anyone in computing get blacklist/whitelist wrong, but the inverted meaning in accounting is a valid point. I think anyone working on the kernel should have a firm grasp of what those terms mean so it's questionable if that's the right place to start though. If and when the world outside the kernel has properly adopted a consistent alternative compatible with accounting is when I think it's appropriate to change the kernel.

Master and slave are actually being used in the proper context though. The master dictates what the slaves should do. It's frequently used in hardware because it's a very robust way to structure control logic; no two slaves can go behind the back of the master and cause hardware glitches.

To explain further, let's look at I2C. I2C is a master/slave protocol where the master handles the data clock and clocks in and out data from what can be thought of as a virtual memory map. Everything the master does is a read or a write. There is no way for slaves to initiate communication in-band and instead rely on out of band communication for such things, usually in the form of an interrupt pin. The only thing the slave has any control over is communication speed where it pulls the data clock pin low for "clock stretching", which tells the master to wait before moving on to the next bit. This feature is used when the slave cannot possibly deliver the next bit but the master shouldn't stop talking to the slave, like when the slave has to wait for hardware to settle in an ADC before it can tell what the analog state was.

There can be multiple masters in I2C but it's relatively rare due to the limited support in master hardware. For master to master communication to work the hardware must be aware that it might not have exclusive control of the bus and check if the bus is available before attempting to use the bus. In addition there are other protocols better suited for peer to peer communications like CAN bus, which doesn't have a master/slave topology. CAN bus is more complex but it's way more robust for communication between intelligent devices. I2C on the other hand is very simple to implement both as a master and a slave; as a master device you have absolute control over the bus (unless it's a multi-master bus) and as a slave you barely even need an internal clock unless it's needed for the operation of the device itself. You can even emulate an I2C master or slave by hand with (debounced) switches if the devices support legacy speeds.

In short, master/slave are the correct terms for a lot of things involving hardware and probably in most uses within the kernel as well.

[Djhg2000]

Realize for a second you're essentially saying I'm fragile for wanting to be treated as human. That's really not a precedent you want to set.

Getting yelled at is treating you as a human. It implies you're being treated as an equal and should know better if you're on the same level.

If on the other hand you were treated with nice words and excuses when you do something wrong, then you're being treated as a lesser person who just doesn't know any better. It would be treating you more like a kid than an equal human.

[skeevy420]

Getting yelled at is treating you as a human. It implies you're being treated as an equal and should know better if you're on the same level.

If on the other hand you were treated with nice words and excuses when you do something wrong, then you're being treated as a lesser person who just doesn't know any better. It would be treating you more like a kid than an equal human.

If you knew my Dad you wouldn't have that point of view. Long story short, prison mentality. To put it another way, my USMC Drill Instructors don't have shit on my Dad's ability to yell and say some nasty, mean stuff.

Basically, what one says when they're yelling matters. For example: "Get the fuck out of here with that bullshit" is a bit different than "Damn you are one stupid fuck. Get out of here with that, that, that gibberish that makes Forrest Gump seem like Einstein. Did your Mom drop you on your head for the fun of it? Seriously, get the fuck out of here with that bullshit."