RE: https://woof.tech/@techokami/117439226690379216

The LLM part is bad news but it isn't the sign. It's the talking about planning succession while simultaneously complaining that nobody new wants to learn, that's the sign.

Y'all the kernel is in deep, deep trouble. We saw what happened to Perl and the kernel is in deep trouble.

To explain what I mean by this: for a long time the Perl community took great pride in how difficult and terse the language was. The old joke that well-written perl was indistinguishable from line noise wasn't just a joke, it was a badge of honour.

That attitude was sustainable when the internet was small and alternatives were scarce. But the moment tools appeared that prioritized things like human ergonomics (python) and human interaction (ruby) the perl community started aging out and dying.

Today the number of people under 50 who'll reach for perl or raku or who cares what it's called as their first choice of tool for anything new is zero. In practice Perl is an esolang now.

Torvalds' position is that contributing to the kernel should be _more_ difficult for everyone else, but, through LLM usage, easier for existing kernel developers.

Ted Tso's adamant position that "you can't make us learn Rust" is the same insularity.

If the kernel was a country, we'd recognize this.

@mhoye

re: "It's the talking about planning secession while simultaneously complaining that nobody new wants to learn"

There are three people identified as "she" in that piece, and one of them was the only person to say something like "[she] said that she can identify the people who will stick around fairly quickly, and some of the new folks who have come in are excellent. For this reason, she still spends a lot of time with people sending spelling fixes. "

It's gendered labor.

There are plenty of good alternatives to driving your community off a cliff like a gaggle of demographic lemmings, but if you're still convinced that mailing lists and insularity are the path to durability in this godforsaken year of our lord two thousand and twenty six then I'm not sure what words will convince you that there's nothing past the edge of that cliff but sharp rocks and seawater.

If your community isn't accessible and welcoming to new, learning participants, the clock's ticking.

And for Linux as a plausibly community-managed meaningfully open as in open project, that clock is definitely ticking.

The end of this road is some corporate-funded retirement home for understaffed and underfunded projects once enough of the current devs have aged out without anyone growing into those roles, with private forks at companies that relied on the kernel, also privately relieved there's no need or reason to deal with antediluvian developer processes or bother giving back anymore.

@mhoye the kernel is a country and it is the united states of america which is actively waging war upon another sovereign state

@hipsterelectron @mhoye you know, I keep beating parts of this drum in conversations with euros

all this "sovereign" tech talk and yet all of them do not seem to have done the slightest bit of analysis on transitive dependency chains

"sovereign distribution, built in europe on european infra" -> look under the hood -> ubuntu

one of the best examples I reach for: "what happens the day you can't reach qemu/kvm source anymore?"

@froztbyte @mhoye it puzzles me frankly particularly the rust part. rust is a microsoft fucking product now but nobody listens to packagers about bootstrap deps. i used rust for 10 years and made the zip crate the safest and fastest zip impl ever and i cannot contribute code to that system again until gccrs is complete

@hipsterelectron @mhoye ito puzzlement, my thesis as to how we got here is: 12~15y of "developer ease"

over the years of flush vc cash shartups, so much focus has shifted from the _outputs_, instead moving to the _personal_. many good engineering things got traded out, simply to "be comfortable"

@froztbyte @mhoye having worked on python packaging until they suddenly released "oh wait this guy is going to make things actually good" https://web.archive.org/web/20250218154403/https://cfp.packaging-con.org/2023/talk/hpuhu7/ and then having astral steal credit for my work and sell to openai and then seeing uv pop up fucking EVERYWHERE having fucking EVERYONE rave about HOW FUCKING FAST IT IS when I FUCKING DID THAT SHIT—i think labor needs rights and protections

Anyway, funny story but remember when the discussion was about The Cathedral and The Bazaar?

There's a second axis to that graph, and it's ends are labelled "A Community" and "A Cult".

@mhoye The "under 50" edit to this just feels like twisting the knife. It's not like it was inaccurate before, but then you had to make it worse.

@fedward Sorry. We hosted a Perl users group meetup at my old shop more than a decade ago, and even then I was the only person under fifty in the room. And now, I'm not under fifty anymore.

@mhoye Linus and his posse have been elitist unwelcoming jerknobs for decades though. If an alternative were to appear, I agree that people would leave them to wither and die. But so far no reasonable alternative has appeared. *BSD, Plan9, etc have all failed to gain traction.

@hal_pomeranz If it's up to me to pontificate, I think it will happen sooner than people might expect. It will either an explicitly anti-AI OS like NetBSD or a pure fork that focuses on a welcoming community and modern tooling.

@mhoye "Torvalds and others repeatedly said low-quality contributions from new developers should receive low priority, and that the community should stop trying to make contribution easy. Many developers said, repeatedly, that trying to mentor those developers is almost always a waste of time; they do not listen."

@gvwilson That part specifically and personally hurt to read.

@mhoye @gvwilson The kernel community is more than mildly interested in alternatives. When you have literally thousands of people showing up throwing slop at you, what do you do to retain your sanity and the quality of your code base? Nobody wants to turn away developers who want to actually learn the kernel and be part of the community, but identifying those people takes time and resources that simply aren't there.

@mhoye > That amount of work cannot be done with a free LLM account. I asked whether that risked cutting off bright new developers that we would rather hang onto; Torvalds answered that the kernel project only wants serious developers. That includes having access to enough resources to function in this world.

"Linux development is only for the wealthy" has probably always been true to some extent but I'm surprised they'd just say it out loud.

@corbet @mhoye @gvwilson and yet the 'community' has managed to drive out several high profile contributors over the last few years, as I recall, mostly over the rust issue - and with few apparent qualms. In my experience people who care about code quality and understanding complex systems tend to strongly skew anti-AI; the kernel's perceived pro-AI stance will likely increasingly put those people off contributing.

@corbet @mhoye @gvwilson I do also wonder if these problems are in some way an unexpected social consequence of a monolithic kernel with in-tree drivers etc. It seemed like a brilliant idea for years/decades, because internal APIs could be refined without piles of compatibility layers, etc - but it also ends up creating a monolithic community.

I've been wondering for a while if a less performant microkernel(ish) approach with defined APIs would make for a healthier social ecosystem. But I guess industry might not have tolerated that performance hit.

@srtcd424 @mhoye @gvwilson There is *one* Rust developer who left after some frustrating experiences. We were sad to lose him. Meanwhile Rust is going from strength to strength in the kernel.

If you look at my Kernel Recipes talk last month, you'll see that, among many other things, I said that the LLM onslaught was likely to cost us developers who don't want to deal with it. To a lesser extent, the advent of Rust may have the same effect. It is not desirable, but I'm not sure what you do about it.

Those who know me know that I am not a big LLM fan. I don't like what they are doing to our community, I fear for the long-term maintainability of a kernel filled with code that its authors don't understand, I detest the time I have had to put into defending LWN against scraper DDoS attacks, I am terrified by the prospect of making our free-software project dependent on proprietary tools owned and developed by psycopaths, I don't believe we can afford the environmental costs, and so on. But the community has to respond to all of this somehow; we're all still trying to figure out what that is.

@mhoye It's a phenomenon I'm seeing a lot in FOSS circles lately: LLMs amplify a benevolent dictators ability to handle things on their own, which feeds into their need for control. That can manifest as anything from unwillingness to share work, to outright messages of hostility to potential recruits.

@corbet@social.kernel.org @mhoye @gvwilson definitely more than one, unless one's incredibly insular and conservative about who's getting counted.

Setting aside the blame-game for a bit, though: for someone who's been tech adjacent for 30+ years, I have a weird sideline in psychology/spirituality (once disparagingly described as a "fluffy bunny dippy hippie.") With that hat on, I do wonder if a lot of people are experiencing a deep/unconscious dissatisfaction with tech, as a primary thing (rather than as a result of e.g. LLM roll-out.) It might actually explain some of the AI-enthusiasm as well, even if that's a very misguided manifestation.

I have a nagging feeling that what we really need to do right now is start radically reducing the complexity and "abstractness" of our society. I'm not at all sure however that we have the time to do that gracefully before the wheels come off.

Returning to OSes, I have no real idea what the right way forward is. If nothing else, we need Linux's hardware support.

@srtcd424 @mhoye @gvwilson As somebody who spends an inordinate amount of time watching this community, I don't know who the "definitely more than one" would be. Since you seemingly do, can you provide me with names, privately if you prefer?

@srtcd424 I am not sure whether my post here is an act of kindness or of vandalism, but here you go for your radical reduction! Make of it what you will. ;-)

https://ecosophia.net/

@paulmckrcu ooh, ta. My reading comprehension/energy is sporadic these days but I will give it a go :)

Many years ago I heard someone attribute a quote to Rudolf Steiner about "the point of absolute materialism from which all progress will be made" - I've never managed to actually find a reference, but it does feel like it describes where we are now.

@srtcd424 @corbet @mhoye @gvwilson I always admired NetBSD s approach to userland and kernel abstractions and the lower kernel to hardware abstractions. That level of flexibility is still remarkable. Runs everywhere may seem like a trite turn of phrase. Or engineering with foresight and hindsight.

@mhoye @hipsterelectron @froztbyte recently I started trying to make a pure Rust Nixpkgs style bootstrap. Assuming you have a Rust compiler binary because that's a given we accept for C ++ (I think an older version of GCC was the only pure-C implementation that was reasonably modern? Less confident on that I thing there might be a C based EDG thing).

But guess what? That's nearly impossible even assuming you start with a binary! First you have to use Cranelift (still billed as experimental, doesn't ship unwinding by default because it possibly bloats binaries though I didn't encounter it) because otherwise you need C++ for LLVM. And even then you don't have an assembler which you need. So okay you write that because I don't think any currently exist.

And then I'm sure you hit some new issue but that's where I stopped for now.

Meanwhile somehow, incredibly, even with the rise of LLM produced projects redoing all kinds of things (I get it, it's a fun exercise) nobody has made a full C compiler in Rust yet. The closest is some Anthropic demonstrator that's been abandoned and isn't finished and a project @jyn started as far as I can tell.

So even if you get there and want to bootstrap from C to a whole compiler chain afterwards to get LLVM support for your Rust, too fucking bad.

I won't accept any issues people claim because you need a compiler binary I think it's arbitrary to allow the C++ compiler but not Rust, but holy shit if your language is going to be self hosting why on earth isn't that actually a full stack even on one platform?

@Lunaphied @mhoye @froztbyte @jyn gcc has a reasonably well-documented bootstrap path from C99. even if i'd like it to be shorter the project takes it seriously and discusses bootstrapping as a concern on the mailing list which i really appreciate. i'm looking to improve the story for emacs atm

@hipsterelectron @froztbyte @mhoye This shit right here is why I am not working on my seL4/Idris crap in public. Giving your shit away to comrades is fundamentally different from giving your shit away to the people in the power structures above you, and we need a way to encode and defend that distinction before we can have free software that doesn't feed the monsters.

@hipsterelectron @froztbyte @mhoye Not that my shit is any good; just look at the rest of what I've put up prior to this if you doubt me. But it's the principle of the thing!

@lykso @froztbyte @mhoye i like idris a lot and i have mixed feelings on seL4 but it is definitely cool software

@hipsterelectron @froztbyte @mhoye Yeah, your work sounds awesome and I am only pursuing the route I am because it seems like a good fit for my relatively limited abilities. These are the pieces I can see and use, and things feel like they are on fire right now so I'm doing what's in front of me. seL4 is juuust beyond the already-available, and I can reach that. You're reaching farther than I am; one day maybe I'll be building atop your work, but laying that groundwork is beyond me.

@lykso that is remarkably kind of you

@froztbyte @jyn @mhoye @hipsterelectron yeah I mean I think it's stupidly long but at least it's possible. But it should still be one step from an existing binary of the compiler to a new binary of the compiler imo

@Lunaphied curious about this since that is generally my experience with gcc. personally my build system will be maintaining an entirely acyclic bootstrap path from C99 and i absolutely agree that should be a goal for every language

@hipsterelectron @Lunaphied C89 should be the goal imo

@wyatt @Lunaphied haven't heard this before and not quite sure of the distinctions but that should probably work. unfortunately i will be cheating by building the whole gcc bootstrap chain which since nobody does that may break in practice

@wyatt @Lunaphied possibly more concerned about OS support but i'm not gonna be doing anything non-POSIX and since i'm doing weird shit to virtualize i/o with patches to gcc i also won't require too much OS support for the fun parts

@hipsterelectron @Lunaphied the main difference for most people is using /* */ for comments

you can use uint8_t and other "standard sized" things and just let the person define them per computer since c89 doesn't standardize them

there are other differences but that gets you like 80% of the way there for no effort

@wyatt @Lunaphied i only use /* */ for comments anyway, // is for losers

@wyatt @hipsterelectron @Lunaphied also variables don't have to be defined at the top of the block since c99 iirc

@SRAZKVT @wyatt @Lunaphied i'm fine with hoisting local vars by hand

@SRAZKVT @wyatt @hipsterelectron @Lunaphied

c89 requires top variables yea
and no vlas, no stdint nor stdbool, no compound literals nor designated initializer, seems like no vararg macros neither (TIL), and libc changes that i don't think matter as much here? idk

@navi @Lunaphied @wyatt @SRAZKVT i'll cry about stdint but if i'm writing C89 i'm probably gonna autoconf up a config.h anyway

@navi @hipsterelectron @Lunaphied @SRAZKVT i'd take navis word for it, she knows her stuff probably a lot more than i do outside my tiny bubble

@hipsterelectron @navi @Lunaphied @SRAZKVT i'm fine with mostly c99 code where i have to manually add a few preprocessor defines like #uint32_t or whatever at the top

@wyatt @Lunaphied @navi @SRAZKVT i'm also concerned about autoconf for other reasons even though zack weinberg is wonderful and very committed to portability. i'm also concerned about automake's perl requirement

@wyatt @Lunaphied @navi @SRAZKVT i implemented functionality equivalent to #include with sed and then made a shell script compiler with more and more sed even though sed is obnoxiously limited and i realized i was building the shell language with built in parsing framework i had always wanted and then resolved to just make that language as a programming language instead of hacking it together

@hipsterelectron @Lunaphied
That's what I'm trying to do though I am adding shims to allow some C23 things to work even on a C99 compiler.
...
Is shims the right word? I've seen the term "polyfills" used for the web but never seen it used for C versions.

@kirtai @Lunaphied as the lone remaining coffeescript contributor i would like to see "polyfills" as a term taken up more broadly. i would also argue "shim" to me evokes OS compat whereas "polyfill" tends to be associated pretty specifically with language versions

@kirtai @Lunaphied i have this awful idea about coffeescript for c i.e. a transpiler generating C89 because it would be terribly simple to implement rust's surprisingly basic unsafe mechanism

@kirtai @Lunaphied it also kinda pisses me off that lifetimes have such complicated inference machinery because it produces terrible fucking error messages and i don't actually want the compiler to infer lifetimes for me in the first place. i've also come to find the mutability restrictions incredibly obnoxious for the single type of code i write all the time i.e. buffered i/o and string search operations

@kirtai @Lunaphied fuck is this just describing C with Classes

@kirtai @Lunaphied here's another thing i don't like about lifetimes which is that they're bound to a mysterious rust-specific concept that essentially translates to nested scopes in the form of stack frames, which like, fine, but rust leaves it to LLVM to actually calculate pointer provenance so information like "this returns a pointer from the same contiguous allocation as provided in argument 1" is not expressible as a type annotation

@kirtai @Lunaphied also coming from coffeescript where the only way to get any type safety at all (i actually implemented JSDoc type annotations which was heroic and nobody cares somehow) is to ensure you dereference a field by name from an enclosing object, it's remarkable to me that rust not only requires a macro to perform struct->field address offsets, but doesn't have a distinct type for "field name X from struct Y", or indeed "offset of some multiple of struct X from address A". these would be really useful to have as visible type annotations imho

@kirtai @Lunaphied one thing coffeescript does that is extremely important is variable hoisting at function scope which also happens to be required by C89 and i would argue is furthermore a really useful thing for a C transpiler to do (in my emacs i have a keybinding that compiles the current file to js and jumps to the corresponding point in the output and this would be very useful for C imho)

@kirtai @Lunaphied also rust does this absurd thing where traits are used for two wildly distinct purposes and they're completely fucked up as a result:

1. ocaml/scala-like matching of function signatures to a concrete function
2. vtable generation with the dyn operator

and i'm pretty sure i've never once wanted the compiler to generate a vtable for me in my entire life, but in order for rust to emulate this very niche c++ feature it requires every trait impl to be implicitly bound to a concrete type i.e. every trait has this secret implicit initial generic type parameter which is desperately confusing and directly leads to most of my issues with lifetimes in traits

@kirtai @Lunaphied this is so crazy! i think this could work!

@kirtai @Lunaphied i could even write this in c++ or whatever because release archives can include the generated output and in particular the very simple file-level module system can be converted to a .h and a .c file and i'm pretty sure i can avoid performing any introspection of C source code

@kirtai @Lunaphied rust does this absolutely TERRIBLE fucking thing where it has this distinct "bindgen" tool that runs clang and generates function prototypes and then rustc just takes you at your word that these functions exist and generates code for them and this is super problematic because the rust libc crate not only does not read your system libc but actively lies about the function signatures because it just fucking packages its own patched musl libc to implement the rust stdlib which is a fucking terrifying thing to do because that comes from microsoft CI along with the rest of the rust toolchain unless you build rust and provide your own musl correctly

@kirtai @Lunaphied and instead of doing anything like that i can completely just compile down to .c and .h and i think everything that might require calling back into C (like asserting a function signature or a struct name) can be expressed by generating a function prototype or by generating a compile test like autoconf has. so maybe it'll be like a .c, a .h, and a .compile_test.c or something so my build system can pick that up

@hipsterelectron @Lunaphied
I wonder how much better things would have been if C++ had stuck with just being "C with Classes"

@thomaswilburn @mhoye I don't think "Linux development is only for the wealthy" is true.

Also, why contributing to the Linux kernel can only be done if you have access to an LLM? I mean, we can still develop like we did 5 years ago.

Personally I wouldn't contribute to projects that promote the usage of LLMs, but I don't see those things related.

@glaskows @thomaswilburn @mhoye because 5 years ago you would be reading and contributing to code written and documented by humans. now you are working on code that is generated by AI and very likely to be unreadable, messy, the documentation could be wrong or incorrect because it was hallucinated, etc etc.

the presence of any ai generated code in a project adds additional mental overhead for any humans working on it.

people who want to code without using AI will give up. people who do want to use AI will remain. more AI generated code will slip in. this vicious cycle will bleed the project of all people who can/want to work on the project by hand untill all that remains is people who depend on an AI to tell them what to do

what i mean by this is no you cant keep coding like you did 5 years ago in a project that allows ai contributions because ai contributions are actively hostile to coding like 5 years ago

@gabu @glaskows @thomaswilburn @mhoye I sincerely want to cry.

And display your toot everywhere. Can I quote it in the readme of my (still private) project, please?

@gabu @glaskows @thomaswilburn @mhoye

5 years ago you would be reading and contributing to code written and documented by humans

Coincidentally, five years ago I actually was working on the Linux kernel and documented is a massive stretch. The code is almost totally bereft of comments. APIs return pointers and the only way to understand who is responsible for cleaning those things up or what the ownership discipline is, is to read other callers and then adopt the consensus view (it’s inconstant you’ll find a bunch of API misuse: if you just copy the first one you find there’s a good chance it will be wrong).

Just to pile onto this some more:

"Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter."

One of and maybe the biggest challenge we had fostering contributors that I - he said patting himself on the back - recognized early when I started at Mozilla, was in coming to terms, structurally, with the fact that free, open software had... won.

That is to say: Firefox 1.0. 2004. A smart kid who wants to contribute to a high-profile open source project with name recognition and global impact had basically four choices: the Linux kernel, the GNU project, the Apache webserver and Firefox; outside serious nerd circles that was basically it.

A decade later, after macports and later homebrew, the explosion of the ruby and python ecosystems, git and GitHub and the entire directional shift of the software world, that kid had 10,000+ choices.

@mhoye I just want to remind folks that ESR was already a nazi when he wrote CATB, and the entire framing was motivated and guided by his ideologies. I'm not sure we have the unadulterated historical memories to evaluate things untainted by that.

A thing I said a lot in those first few years was: we are competing on the experience and ergonomics of being a part of this community. Every single person out there who is smart enough to turn the crank on a compiler and figure out how to send us a patch has thousands of options. The process complexity and hard-knock oldschool open source "culture" we believe is acting as a "filter" isn't selecting for brains or talent, it's selecting for a willingness to tolerate bullshit and endure abuse.

@mhoye I'm skeptical that "wants to contribute to a high-profile open source project with name recognition" should be a goal anyone should be supporting.

That's the mindset that got us into the shit we're in: FOSS as a way to get one's foot in the door for cushy tech industry careers, not as a way to take a problem you understand and care about and make things better for yourself and others.

It promotes the same kind of behavior in FOSS as the Google "breaking shit to get a promotion".

And to be explicit about this: a long-running filter that's selecting for a willingness to tolerate bullshit and endure abuse is exceedingly useful if you're a terrible manager or a sex pest, two classes of people who have notably flourished in free software for a very long time.

But when smart people have choices, and they choose not to tolerate mismanagement and abuse and stop choosing you, either you grow up or soon all you have are people who think abuse and mismanagement are normal.

And you can call this oversensitive, feel-good "woke" nonsense if you want, but I've got the data and I'm right: a code of conduct, community standards and moderation enforcing them, the psychological safety of your community, these are near term competitive advantages and long term survival necessities. Treating the process of getting involved and the experience of staying involved in your community _as a product_, worthy of usability testing and ergonomic refinement, that moves the needle.

@mhoye I think this is a good thread.

@mhoye Developers also have more choices outside the "Free Software"/"Open Source" scene now.

When all this stuff got started, the transaction costs of proprietary meant that if you started on a student/hobbyist budget and wanted to do globally useful software, free was the main option.

Now mobile app stores make non-free projects even lower hassle than free ones. And SaaS platforms aren't much harder. The overhead advantage of participating in open source went away while the downsides stayed.

We gave the entire (well, no-PII, no active secbugs, etc) contents and history of Bugzilla to some very smart PhDs at uMontreal, and one of the things they came back with was this: somebody submitting their first bugfix was relatively unlikely to submit a second, but somebody on their fourth bugfix is quite likely to get to five, and six, and stick around.

I cannot emphasize enough how much you get from up front code ergonomics and human care in the early stages of the contributor relationship.

@mhoye much earlier this year I basically gave up on an attempt to contribute to Matplotlib because the process was so painful. Like, the existing code also had issues, but that's never a big deal for me. But I would need day job money to deal with their CI setup or their patch notes process, let alone both. It's not that I couldn't soldier through it if I needed to. It's that I couldn't justify spending my life that way.

@lrhodes @mhoye@cosocial.Some Examples?

@LAG_Netzpolitik_BW I remember reading an interview (or possibly a quote from the mailing list) from Torvalds a few years back, in which he intimated that he no longer wrote code at all; he had long since lapsed into managing the contributions of his devs, was what he seemed to be saying.

That he is now apparently back doing "contributions" himself with LLMs absolutely fits the profile of what @lrhodes was talking about.

@mhoye@cosocial

@srtcd424 Glad you like it, but as they say, be careful what you wish for. You might get it. ;-)

@dalias @mhoye I can second that from the contributor side (in my younger days). It meant I ended up with less team loyalty, less systemic knowledge, and a lot of (internal) inappropriate reactions to setbacks and obstacles. It also led me to make some bad choices of projects to contribute to, not in the sense of the project being objectively bad, just not a good fit for me. None of that applied to the work I did for the right reasons.

On the other side of that coin, the psychological safety part of it, a true story: I'm the guy who killed IRC at Mozilla. I'm proud of it.

One of the reasons I'm proud of it is the mobile IRC bouncers that didn't let people delete old DMs so I got to have conversations with colleagues where they showed me pages and pages and pages of vicious scrollback harassment that they had to endure for their jobs, sitting in their phones forever.

The feature request was "I just want this to stop."

The move to Matrix was partly driven by their open source commitments - hi, @matrix , hey yo, love you all - but they mostly won on the strength of two things. First that their accessibility posture was not just unrivalled in terms of FOSS forums but that their team jumped at the chance to work with us improve it.

But 2nd: the moderation tools are unmatched. Nothing else comes close.

Once you have tools and process in place to ablate harassment, nobody willingly goes back to not having that.

Like, OK, we've got clean running water now, we've got soap, we've got [checks notes] the forum management equivalent of an orbital ion cannon for dealing with the abuse or harassment of our community in our open forums., and I guess we're on our way to penicillin. We're going to be OK.

Being trusted to provide the foundations and tooling of that psychological safety to a team of the finest people I have ever worked with, and delivering on that promise, has been the high point of my career.

@mhoye sounds like a really shitty place to work if that behaviour was expected. was this via a public irc server or internal only?

@waffles The combination of the long running and deep seated cultural expectation of working in the open, the fact that for many years IRC was the only suitable tool for that and that later alternatives were almost all proprietary or otherwise closed meant we held onto it for very good, values-forward reasons, for a lot longer than we should have.

@MaddieM4 @mhoye I tried to contribute to firefox a decade ago (or so) and the level complexity with the use of multiple languages meant that after going through multiple layers it become clear that implementing the simple feature I wanted to add would far exceed the time I could afford. I could imagine contributing to the kernel, but I will like opt for a simpler kernel that uses C exclusively for similar reasons... Too much industry-level complexity in Linux already.

But again, there it's the same story. Matrix is still a _little_ convoluted as far as onboarding is concerned, but it beats the heck out of IRC's "learn a new OS and hope you don't get disconnected" cliffs-of-Dover learning curve, and the numbers again reflected that. Invest in community accessibility, and community safety and tooling ergonomics, and the line goes up.

Not a line made out of rageclicks, manipulation and misery, just the steady growth of a community worth being a part of.

@mhoye Is there an inventory of the capabilities you & yrs found particularly valuable somewhere?

@owen When we got it spun up, the weapon of choice was called Mjolnir. Today, you want to look at its successor Draupnir.

You need to know a _little_ about how Matrix communications are structured and work, but relatively little. Single-action org-wide banning, per-user or per-origin, is a delight, and retroactive redact was something that a few free-as-in-speechies objected to until the day I had to clean up a goatse flood, they came around pretty quick after that.

https://github.com/the-draupnir-project/Draupnir

@paulmckrcu oh, on a personal level I think I've been round that loop a few times. A lot of what U. G. Krishnamurti said to people who thought they wanted to replicate his path has come back to me over the years!

Anyway: the Linux kernel could have that. Any community can have that, really. But the real work is the humility of admitting you might need it.

And a lot of people - not just proud but _justifiably_ proud, for all their accomplishments and success - can easily find themselves trapped in the kind of blind spot you can only be trapped in by the atrophy of that humility, from a mere failure to welcome and foster enough diversity and dissent.

Where you can no longer change without failing first.

@mhoye Thanks.

Going off a quick read, it seems like a lot of its underlying thesis is in the direction that if you have to moderate someone in one spot, odds are they've been up to antisocial nonsense in several, and you might want to act on them without having to individually find and adjudicate them. That tracks - but am I reading it right?

@owen During my full-time involvement, it was still true that moderators had to generally keep track of disparate acts across forums, and communicate appropriately.

Early on, this was a lot of administrative work for me - most abusers get away with it by being perfectly nice to most people - but after a while I'd built up enough credibility that people came to value the safety of their colleagues in other fora very highly.

@mhoye (The background radiation of most moderation on the internet is to treat each incident as a one-off; tooling for addressing repeat customers is frequently weak)

@MaddieM4 @dalias @mhoye

for decades I'd always thought at least half of FOSS is just gig workers trying to build their CVs/portfolios to get paid corporate work, and seen (especially in AV/multimedia and telecoms) countless FOSS projects enshittify and commercialise as soon as they became popular and others gatekeep support/solution finding to nudge folk towards paid solutions (especially SaaS) to the point I've become cynical about the whole thing and often just stay on Windows as the cost of many proprietary solutions has plummeted (and some things like specialist automotive coding software and hardware simply don't have FOSS equivalents and likely never will..

@mhoye

The more competent you are, the more important humility is.

Never listen to your own press. Always put yourself in other people's places. Never internalize people's praise of you and your work. Always listen to others' experiences of your work, and of you.

Yes, you have to decide who to listen to, but still.

@mwl https://www.youtube.com/watch?v=uPiH-LBna5I

Anyway: The worst thing an organization's leaders tolerate is what that organization becomes, and the blast radius of a single toxic contributor is huge and largely invisible. For everyone who speaks up to say this behavior isn't acceptable, there are dozens or hundreds of smart, competent people who peer into your community, see that this is how you live and move along without your ever knowing they exist, on their way to a better life somewhere else.

We don't have to live like this.

@mhoye yeah, and I sincerely hope @torvalds bans #AIslop from #Linux before the #Enshittification with #SlopCode makes it so unmaintainable that everyone has to jump back to linux-6.6.6 as safe point…

@Netzblockierer @torvalds only started so loving ai because it could make a python ui for him, should we trust a project ran by someone who is either/both unable or unwilling to learn python? @mhoye

@sackofbones @torvalds @mhoye I'm not skilled enough in C to consider maintaining a fork…

@Netzblockierer Neither am I, I could do it in Rust or C#(if I could run direct on x64) tho... @torvalds @mhoye

@mhoye @waffles I'd also be interested to know the answer to the question waffles asks, though.

@denisbloodnok @waffles irc.mozilla.org was a public server, yes.

@dalias
Could you explain how that framing showed? I read the piece as an enthusiastic teen back in the day and don't remember finding it very nazi at the time, but I may have been tone deaf, so idk.
@mhoye

@hllizi @mhoye I don't think it was pushing a specifically *nazi* agenda there, but he had very strongly held ideas about human motivation, how human beings organize their activities, and what sorts of organizing should be encouraged or discouraged.

Remember this all came around the same time of his mission to replace Free Software with Open Source and make the whole thing appealing to capitalists for the purpose of appropriating free (lowercase-f) labor.

@dalias
I would, from how I remember things, rather agree to that wrt to his land ownership shtick in Homesteading the Noosphere.
@mhoye

@hllizi @mhoye Yeah that's the one I always bring up when people are like "no, he was okay back then, he only became a nazi later".

Those specific words, "Homesteading the Noosphere", are something you do not come up with unless you're already deep in the rabbithole of far-right crankery.

A final, selfish addendum to this: I do consulting work around questions of cultural health, process improvement and accessible cultural change. If you'd like to have a conversation about that, let me know.

@srtcd424 @corbet @mhoye @gvwilson

It seemed like a brilliant idea for years/decades

It was decried as an awful idea by literally anyone caring about security or maintainability for just as long.

Even before considering many of the corposcum-contributed drivers are so obfuscated and underdocumented they might as well be blobs (some literally do include mystery blobs as variables).

I've been wondering for a while if a less performant microkernel(ish) approach with defined APIs would make for a healthier social ecosystem.

It would.

@corbet @mhoye @srtcd424 @gvwilson

I fear for the long-term maintainability of a kernel filled with code that its authors don't understand

I don't want to run any such kernel or code, either.

@mhoye The unfortunate thing about the move to Matrix is significantly more discussion started happening on Mozilla-internal Slack at the same time, and that really killed some of the open-by-default vibes, with some people scarcely checking Matrix.

@gsnedders That didn't happen at the same time; the reality is that IRC usability was, compared to what was available, just so bad for so long that long before a single Mozilla slack instance was blessed, long before I was sent to get us an alternative to IRC, there were already _dozens and dozens_ of private shadow Slack instances all over the place for various teams and projects. Like, on the order of 180 of them. One of the biggest impetuses for moving to Slack was... most people already had.

@mhoye this is a great thread, and I agree with all of it except this tangential point.

Matrix moderation tools are a chaotic mess. Some of that is inherent distsys problems, some of that is missing / bad protocol design or poor integration. Not all of it is directly related to moderation being a reactive afterthought, but is compounded by the combination of that with general matrix desync artifacts.

Speaking from experience doing matrix moderation, notably during an especially nasty period a year or two ago, there is plenty of capability left to build. While the more centralised platforms have some inherent advantages here, that's not the only reason their moderation capabilities are easier to operate effectively.

There are tools. Many different variants, even. That they are better than what IRC has is not in dispute, but that's the lowest of low bars.

ETA: The people building the tools are working on the fringes and get easily burned out, for obvious additional reasons beyond all the normal and accelerating reasons everyone else is These Days.

@uep so, it’s been 3+ years admittedly but that was not my experience at all. I don’t want to tell you you’re holding it wrong, and I haven’t had an opportunity to flex the new Draupnir tooling, but my experience was definitely not what you’re describing.

(Slack’s moderation tools basically don’t exist and IRC’s are trash, on this we agree)

@mhoye i work and plead mors on the build tool and compiler and rest of tech tool aspect side of things with the same arguments.

And I think it is far less important than the one you point out (and probably harder to fix funnily enough).

So thank you for expressing it <3

@sackofbones @Netzblockierer @torvalds @mhoye Perhaps consider trusting a project (and its leader) that have delivered increasingly capable kernels and a strong development community for 35 years?

I am not thrilled (to put it lightly) about this rush to LLMs, but I don't think that this sort of attitude makes things better.

@corbet No I don't think I will. He's turned into a bourgeois elitist prick anyway
@mhoye @torvalds @Netzblockierer

@srtcd424 Fair enough! ;-)

@mhoye tldr; #LLMs are here to stay. People who actually deliver working solutions that shape the world have spoken. Measures to limit slop are being developed. #Linux becomes even more commercial.
I personally hope more open models will arrive, GPUs will become cheaper and universal income will help people who wont be able to find job in such toxic and draining field as computer science.

2026 welcome in ultimate hell everyone! Dont forget to enjoy the ride!

@grayrattus @mhoye How do cheaper gpus make universal income possible? The wealth hoarding class can make universal income a reality right now.

@Howitzer105mm @grayrattus You can see it's definitely a well-thought out position.

@hipsterelectron @kirtai @Lunaphied to me a polyfill is specifically equivalent in functionality to whatever is being polyfilled whereas a shim doesn't need to be.
so you'd polyfill a modern api you don't have yet, but you'd shim a tracking api, for example.

@Netzblockierer @mhoye @torvalds that's likely never going to happen, I would advise finding or establishing a fork. Isn't that the great promise of open source? I don't understand a lot of the whinging around this topic because by my estimation schisms are nothing new to humans, digital or meat space.

@burly @mhoye @torvalds yes, I guess people will archive & #fork #linux and/or use #illumos nee #OpenSolaris, #NetBSD, #FreeBSD or #OpenBSD kernels.

I talked to the maintainer of _OS/1337 and his justification re: Linux as Kernel is the #documentation and #drivers…