Message-ID: <CAPKFLCRNQxcvSwyy6LckOPKV8EgBPe8DyOGYAwbGfs6VoRg2cw@mail.gmail.com>
Date: Sun, 28 Sep 2025 09:28:03 +1000
From: Sebastian Ramadan <slay.sebbeh@...il.com>
To: linux-kernel@...r.kernel.org
Subject: Culture of unprofessionalism & lack of accountability for apologies

Hi all,

I want to take a moment to reflect on an uncomfortable but necessary
topic: the persistence of unprofessionalism in kernel development
culture, particularly flippant public attacks that were supposed to
have been addressed long ago.

In 2018, Linus publicly acknowledged the damage caused by his
communication style, apologized for personal attacks, and expressed a
commitment to change. That was a moment of clarity for many of us — a
chance to move the project toward a healthier, more respectful
environment. But when similar behavior resurfaces years later, as seen
in the recent RISC-V thread, it calls into question whether any of
that change was genuine or lasting.

The public dismissal of Palmers work — someone who has long
contributed to a difficult and evolving architecture — in the tone it
was done, doesn't just hurt individual contributors. It undermines the
entire community's claim to professional standards. The lack of a
public apology or even acknowledgment this time around echoes a
pattern: apologies are made, but responsibility is dodged when it
matters.

It's especially ironic considering that the criticism targeted code
meant to improve portability — a topic that, frankly, is often handled
with more rigor in the BSD community, where standard C and actual
cross-platform semantics are taken seriously. Palmers work, from what
I've seen, reflects a real effort in that direction. If anything, he'd
likely find a more appreciative and standards-conscious home among the
BSD maintainers.

This isn't about hurt feelings — it's about creating a development
environment where criticism is grounded in substance, not theatrics,
where accountability means maintaining professional standards *even
when frustrated*, *especially when frustrated*.

We all want a better kernel. But we can't keep sweeping this stuff
under the rug. The damage doesn't go away just because no one brings
it up again.

—Sebastian

P.S. The average lifespan of a mainstream operating system is around
20–30 years before it becomes either legacy or niche. Unix is over 50.
Linux is past 30. What started as a lean, clever system for
underpowered machines has calcified into a monolith propped up by
legacy assumptions and controlled by individuals who still treat
community engagement like trench warfare. At some point, we have to
ask whether we're preserving something valuable — or just refusing to
let go. Modern hardware is no longer well-served by the abstractions
Unix was built around. Modern features in our hardware are
increasingly *misrepresented* or outright ignored by legacy APIs and
kernel boundaries. We've reached the point where the software
interface is not just mismatched with the hardware — it's a bottleneck
to using it correctly. No amount of flamewars about where code should
and shouldn't be will paper over that. In fact, if we're to get into
an inflammatory discussion about what code should exist and where,
here it is: Linux shouldn't exist on our modern hardware...

Powered by blists - more mailing lists