why they feel it’s Linus’ responsibility to make Rust happen in the kernel
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
“Let’s wait and C”.
aughhhhhh here’s your upvote. git out.
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.