This is something I keep trying to point out to people. That doesn't mean that Linus is any kind of role model in this way - but people point to open-source interactions as especially "toxic" while ignoring (or being ignorant of) the fact that things are often _far worse_ behind closed doors. The differences being that 1) they're behind closed doors and therefore rarely seen, and 2) calling out a rude interactions in open-source projects is unlikely to get you fired or on the wrong exec's shitlist.

I thought he got way too much stick for that. Most of the rants all seemed to be at senior people who should have known better trying to break ironclad, well established rules that exist for a very good reason (e.g. "we don't break userspace mauro").

Look at the rants without understanding the context (which, frankly, most people don't - kernel development is pretty arcane) and the rants look worse than they really were.

Just because you've seen worse doesn't excuse it. Everyone who behaves this way should find ways to deal with their emotions in a healthy way that doesn't negatively affect others.

This.

I love the way Linus rants in public.

When I was 24, I got a rant in private from PG, and it was pretty shocking at the time:

"You guys just set a new all-time record in losing by being based in SF and skipping events at YC. I doubt it will ever be surpassed. Peter Thiel was speaking today. When he described the kind of companies he liked to invest in, he was describing Jobpic. So after his speech I jumped up and excitedly told him about you. He was very intrigued by the idea. I went off to find you to introduce you, and you're not here.

At least now I'll have a really good story when I tell each new batch that they'll miss out if they live in the city.

--pg"

3 notes:

1. He was right, my cofounder should have been there (I couldnt be there).

2. The hyperbole made it memorable. My friends still tease me about this "playing hard to get with Peter Thiel? Ballsy"

3. The only sad thing is people are afraid to be like this in public, and put on a more politically correct face in public. Linus has had the guts to be the same person in public and private. Something worth emulating.

Related read: https://breckyunits.com/assholes.html

That behaviour sucks and is not acceptable. Sorry that you have had shitty coworkers in corporate America. That’s not what the world is.

This is absolutely true. It's also difficult to judge how much otherwise obnoxious developers take advantage of "niceness" from outside the zoo looking in. These situations were almost necessarily interpreted out of context without catching up on years of mailing list culture.

I worked for a Japanese company that employed some of the top engineers and scientists in the world.

The Japanese don't really like yelling and screaming, but I have watched managers reduce subordinates to tears, with a few firm words (literally).

Also, some of these top-shelf engineers could be "pithy." They didn't suffer fools, and had the attitude that if you were working directly with them, it was assumed that you were at a level that would not interfere with their work (like having to constantly stop and explain stuff).

Their end-product was really good, but it took a very strident culture to get there.

I assume that the Linux Kernel is just such a product. I can certainly understand the stress on making sure that anything that goes in there, needs to be absolutely top-notch. Not just in code Quality, but also in the mindset of the people submitting it.

I will also say that, if we want top be top performers, ourselves, we need to be willing to be in situations, where we could be yelled at, told our work is shite, etc.

It would be nice, if we were gentler than those than go before us, but this type of thing tends to self-regulate. If a top performer is so toxic that no one can work with them, they can get shown the door. That was not always the case, but I think it is increasingly so, these days.

But that doesn't mean that top performers are required to coddle; maybe just not outright abuse.

On a somewhat related note, I've been enjoying watching Slow Horses, and the Jackson Lamb character brings back memories.

> Rust's main problem is that libc is effectively the system API on POSIX.

True, that is what makes things harder for Rust in practice.

But interestingly, theoretically speaking it's more C's problem rather than Rust's - a legacy effect originating from the UNIX-C co-evolution. Good design would command a stricter separation of concerns/sub-systems (some LISP machine people will disagree, and I say it because there are a ton of them on HN, of course).

"Not engaging at all" allows the engaging group to completely take over and expunge their opposition. The Python Software Foundation is an example. They have multiple former directors banned or resigning. They've defunded African Pycons that won't embrace certain ideologies. PSF employees and work group members are being purged of anyone not fully on board with the new ruling party. The discussion forums are censored and long-term contributors are afraid to post.

In general, in democratic organizations it is a failing strategy to not engage in arguments or to boycott elections. It is a recipe for an imbalance that is almost impossible to correct later.

So, I respectfully disagree with your suggestion to not engage at all.

I disagree, to an extent as you created a dichotomy between tech and religious arguments. The truth is there is a spectrum, where a compiler error is a purely technical discussion. On the other hand of the spectrum are loosely related to tech like, "I need to see more from you before we tackle bigger changes".

Open source is definitely very political and if you are not political you will find you will produce lots of technical output that will never be merged. There is also lots of etiquette that can go to using mailing list and patchset formatting to knowing who to ask to review. When you talk about design changes you better have credibility, as your design might not even be evaluated if you do not have a track record. I really disagree with your comment and in my experience with lots of OSS different projects i contributed to, i can tell you politics is equal or more important than raw technical competence the bigger the project is.

I think this will happen sooner than we think. Lots of not-old people with a lot of talents out there and who doesn't like "get off my lawn" culture of the Kernel.

They key aspect will be importing was has gone wrong in the Rust and kernel community cultures.

There is no such thing as a Linux-compatible kernel. There's only Linux. Linux is not even compatible with itself, it's only compatible with its major version number.

The argument may have been 'go pound sand', that's what it means.

There is no reason anyone smart enough to work in the kernel could not learn Rust, C++, zig, Java, Scheme, or whatever language you can dream of. However the above list is far longer than anyone has time to learn and so the kernel should limit the languages allowed just so that the list of what you need to know is reasonable. (I haven't looked at linux code in 20 years, but back then you needed to know C, sh, and make - you probably forgot that make is a language but it is/was critical) It is reasonable to say that all kernel programmers need to know rust from this day on. It would not be reasonable to say any language is allowed. It would be reasonable in 30 years to discover there is almost no C left and so rewrite the rest and ban C (I won't bet money on that happening but it is reasonable)

It doesn't seem reasonable to expect a developer to learn a new programming language? Staying on top of constantly changing tools is part of the job.

You forgot about the third option: specify "stable" and properly documented API boundaries in relevant subsystems. Developers of Rust drivers would have to rely only on those APIs, in turn, if subsystem maintainers want to change those APIs, they would have to synchronize it with Rust developers.

The problem is that some subsystem maintainers do not want to even properly document existing APIs (sic!) and want to reserve the right to willy-nilly hack some changes into "their" subsystems without discussing it with other stakeholders.

Is Scala actually dead?

Thank you for your reply. I had suspected it was the second chance pool but I had never seen that mechanism in action so I thought it'd get re-posted, not that it would appear as if it had just been posted. I had read it when it first appeared.