3 ms·

I have looked at several reverts and their review comments. Obviously none of those were hypocrite. The biggest problem is that even experienced kernel develope

I have looked at several reverts and their review comments. Obviously none of those were hypocrite. The biggest problem is that even experienced kernel developers far too often cannot clearly decide whether the code is better with or without the patch. There are several reasons: * C is not an easy language that makes it hard to write unsafe code * hardware can fail in any unspecified way * the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.) My performance and scalability requirements are much less than what the Linux kernel can do. So if there were a serious competitor based on code that humans can understand, my choice would be clear. In lack of such option I continue to use Linux and hope that nothing too bad happens...

yjftsjthsd-h 6y ago
> The biggest problem is that even experienced kernel developers far too often cannot clearly decide whether the code is better with or without the patch. It was a bulk revert; not "we can't tell if these are bad" but "we're reverting all of these until we can re-review them". Or, if you're claiming they shouldn't have been merged in the first place if it wasn't possible to be 100% confident in them... that's not how humans work, nor programming. Even if you specify your code in coq or something, you still have to verify that the model is correct and there's still room for human error. > the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.) Yes, they should have followed in the footsteps of all those other successful feature-complete microkernels like, um.... maybe QNX? Maybe? To be fair, I don't know that there's a reason why microkernels seem stuck in the "theoretically great but nobody's made one that works in the real world", but here we are. So in broad strokes: You seem to be very confident that if kernel devs would just Do It Right then they could eliminate all bugs and malicious code, but this seems unlikely.
- usr1106 6y ago
  > You seem to be very confident that if kernel devs would just Do It Right then they could eliminate all bugs and malicious code You wrote that, I didn't. The Linux kernel has chosen its route, I am not going tell them that they should do different. All I say is should be possible to write a kernel that is reviewable by more people. It will be less scalable and less performant. But that's a price I might be ready to pay both for myself and for my work. My machines are hardly ever limited by kernel performance. Others might certainly have use cases where that is not true.
jnxx 6y ago
> * the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.) You should just run Minix.
- usr1106 6y ago
  I don't think Minix is actively maintained. Intel secretly chose to run Minix for their ME and the results have been desastrous. I run Linux because it's the best option available today. That does not mean it's the best option conceivable if you value simplicity and visible robustness over performance and scalability.

yjftsjthsd-h 6y ago

> The biggest problem is that even experienced kernel developers far too often cannot clearly decide whether the code is better with or without the patch. It was a bulk revert; not "we can't tell if these are bad" but "we're reverting all of these until we can re-review them". Or, if you're claiming they shouldn't have been merged in the first place if it wasn't possible to be 100% confident in them... that's not how humans work, nor programming. Even if you specify your code in coq or something, you still have to verify that the model is correct and there's still room for human error. > the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.) Yes, they should have followed in the footsteps of all those other successful feature-complete microkernels like, um.... maybe QNX? Maybe? To be fair, I don't know that there's a reason why microkernels seem stuck in the "theoretically great but nobody's made one that works in the real world", but here we are. So in broad strokes: You seem to be very confident that if kernel devs would just Do It Right then they could eliminate all bugs and malicious code, but this seems unlikely.

usr1106 6y ago
> You seem to be very confident that if kernel devs would just Do It Right then they could eliminate all bugs and malicious code You wrote that, I didn't. The Linux kernel has chosen its route, I am not going tell them that they should do different. All I say is should be possible to write a kernel that is reviewable by more people. It will be less scalable and less performant. But that's a price I might be ready to pay both for myself and for my work. My machines are hardly ever limited by kernel performance. Others might certainly have use cases where that is not true.

jnxx 6y ago

> * the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.) You should just run Minix.

usr1106 6y ago
I don't think Minix is actively maintained. Intel secretly chose to run Minix for their ME and the results have been desastrous. I run Linux because it's the best option available today. That does not mean it's the best option conceivable if you value simplicity and visible robustness over performance and scalability.