Comment by arjie | Hacker News Reader

Comment by arjie | Hacker News Reader

The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim/neovim schism happened and perhaps that's how it ends. I personally like Neovim and I'm glad to be in backers.md and it's a tremendously larger amount of work than to have just changed vim. But c'est la vie.

Egcs vs. gcc was a big deal back in the day and in the end we ended up with gcc by the egcs guys and that was it. When you win, everyone forgets the 'drama' existed. When you lose, everyone remembers you as just the drama guy. RMS had the drama label for decades. Things are not even different. They're the same again. It's like when you'd buy those Chinese NES dupes and they'd have 999 levels of Mario but half the levels would be the same but with different colour bricks. Isomorphic to original but distinct. That's this story.

if your lens is old-bad vs new-good, you are blind to merits.

didn't the good egcs stuff get merged after all?

> didn't the good egcs stuff get merged after all?

EGCS took over as mainline, and what good stuff there was in the old mainline got merged into it. But it took sustaining the fork for years to make that happen.

> The new-school guys want to make things better in a new way.

The new guys definitely want to make things different, but it seems there is a lot of debate over whether it will actually be better. Really, they should just write their own their kernel. If rust is really that much better, they'll will.

There are already kernels written in Rust. Telling them to go write new kernels in Rust is like telling people working on a new audio workstation that they should write a package manager instead. A new kernel that they cannot practically use does not suit their needs. The point is to use Rust where it can suit their needs.

Why are they entitled to the existing kernel? By what right?

They were invited to by Linus and Greg KH...

Well I certainly don't use linux because it's written in C. Who would?

Edit: This seems like more of an indication of a culture that lacks effective conflict resolution than any kind of technical question.

>The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way

The new school guys greatly underappreciate the wisdom of why and instead try to change things without first understanding.

This seems quite ironic to say when the whole drama started with Christoph not even looking at the patches long enough to see what directory they were in before rejecting them.

Isn't the charitable interpretation that the subsystem he is a maintainer of is downstream from the proposed changes?

I mean, no, because the straightforwards reading of his first email doesn't match with the facts. He said "no rust code in kernel/DMA" when the patch did not add any rust code to kernel/DMA.

The fact that the patch wraps kernel/DMA is why he was CC'd in the first place, but that doesn't give him authority to unilaterally reject it any more than he would have the authority to reject an Nvidia driver for using DMA.

What would happen in that case (and is likely to also happen in this one) is that CH's objection will be completely ignored, because it's absurd. Maintaining the DMA subsystem doesn't give you veto rights against every driver or subsystem that needs to use it.

Apologies, that I can onboard with, I was just speaking about the comment.

The old school guys do things for a certain reason that young contributors often don't appreciate. Enough violations of that, and you're often ignored. Perhaps thats what has happened here?

Clearly this is a communication problem more than anything else.

That's not what happened here.

https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...

What happened here? Years ago Linus was talking about how he thought positively about Rust in the Kernel in the future if the kinks could be worked out. Now a group of people have built out a set of drivers which are working great, well tested and integrated, and one maintainer has decided they just don't want to merge it so the whole project is indefinitely stalled.

I'd be pretty upset if I was working on Asahi since the Linux project has basically bait and switched them after an enormous amount of work has been invested.

The project isn't stalled they can implement it directly in the driver, they wanted to put it together with DMA code because it wouldn't need to be copied to every driver, what's fine, but the project isn't stalled

> The old-school guys want to keep things old-school.

You are missing the whole point here. The kernel is a survival epic amongst millions of other failed projects. You don't get to tell the old captain and its lieutenants how to nail the planks and helm the ship when you just went pass the Titanic and Britannic wrecks because metal is so cool.

They're "old-school" because they have to be. Engineers will excrete their pet project and then leave and now they will have to support it. They are mean because that's the only "power" they have, as is explained in the post.

I'll leave you with this quote from "The Night Watch" by James Mickens (https://www.usenix.org/system/files/1311_05-08_mickens.pdf)

> This is not the world of the systems hacker. When you debug a distributed system or an OS kernel, you do it Texas-style. You gather some mean, stoic people, people who have seen things die, and you get some primitive tools, like a compass and a rucksack and a stick that’s pointed on one end, and you walk into the wilderness and you look for trouble, possibly while using chewing tobacco. As a systems hacker, you must be pre- pared to do savage things, unspeakable things, to kill runaway threads with your bare hands, to write directly to network ports using telnet and an old copy of an RFC that you found in the Vatican. When you debug systems code, there are no high- level debates about font choices and the best kind of turquoise, because this is the Old Testament, an angry and monochro- matic world, and it doesn’t matter whether your Arial is Bold or Condensed when people are covered in boils and pestilence and Egyptian pharaoh oppression. HCI people discover bugs by receiving a concerned email from their therapist. Systems people discover bugs by waking up and discovering that their first-born children are missing and “ETIMEDOUT ” has been written in blood on the wall. What is despair? I have known it—hear my song. Despair is when you’re debugging a kernel driver and you look at a mem- ory dump and you see that a pointer has a value of 7. THERE IS NO HARDWARE ARCHITECTURE THAT IS ALIGNED ON 7. Furthermore, 7 IS TOO SMALL AND ONLY EVIL CODE WOULD TRY TO ACCESS SMALL NUMBER MEMORY. Misaligned, small-number memory accesses have stolen decades from my life. The only things worse than misaligned, small-number memory accesses are accesses with aligned buf- fer pointers, but impossibly large buffer lengths. Nothing ruins a Friday at 5 P.M. faster than taking one last pass through the log file and discovering a word-aligned buffer address, but a buffer length of NUMBER OF ELECTRONS IN THE UNI- VERSE.

The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation. So OP's description seems more apt than yours.

https://www.youtube.com/watch?v=OvuEYtkOH88&t=367s

Linus doesn't write much code anymore. The ones who are responsible and doing the heavy lifting and taking the heat when things break are the often unpaid maintainers. You can't say OP is more apt when he probably never done this work before.

I have to work with a "kernel a-hole". Sure it sucks but when there's some mutex bug in a chip driver, he's the one we can call and fix the problem and push the fix upstream even though he's already overworked. He's an a-hole but I respect his rules because he's the one suffering and pulling in the work and I don't.

Yes the kernel is stagnating (patches and email mailing list, line length limited to be compatible with old tty terminal, etc.) but when you're at the helm of a ship you don't just steer it near the nice looking island just because it looks pretty and there doesn't seem to have rocks.

The kernel is full of (a-)holes (both the code and the project), because the a-holes drive away the people who would help fix the holes.

Yes, it works, but there's a very real opportunity cost paid every day, month, release. It works until it doesn't. (Marcan crashed and burned out. But sure it works. And ... after all, since there's no real alternative we just pretend that it works. So as I was saying, it works! It's alive!)

Of course it's not easy to set boundaries, but the whole "patches are welcome" sets up false hope and masks the real incompetence in managing the kernel. (And of course is the focal point of the broader, very human tragedy of the Linux and FOSS ecosystem. insert obiligatory xkcd 2347 link here)

> The ones who are responsible and doing the heavy lifting and taking the heat when things break are the often unpaid maintainers.

Only 13.3% of all changesets are from people that are either unemployed or their job is unknown [1].

Even greg k-h said that most of the development is backed by big companies so the argument of 'poor unpaid maintainers' doesn't go too far.

[1] https://lwn.net/Articles/1004998/

Reply on news.ycombinator.com