4 ms·

> The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it'

by jorvi 2y ago

> The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. Isn't that the Linux kernel in a nutshell? Of the top of my head I can name: - The zram maintainer that's for a few years been blocking the patches that add the zpool api to zram. This would go a long way to unifying zram and zswap in the future. - TuxOnIce being permablocked by some heels-in-sand maintainers until the kernel diverged to much and the patch writer gave up. This one would have fixed hibernation on Linux.. in other words, hibernation still sucks because of these maintainers. - Of course the trench warfare all the C-proficient maintainers are waging to chase all the Rust-in-Linux people away, lest they have to learn Rust. ~80% of CVEs are memory-related, so you could say that in say.. 10 years time, ~80% of the CVEs happening in the Linux kernel are the legacy of Ted & co.

vlovich123 2y ago
You can roughly be: 1. Wrong and ignorant 2. Wrong and knowledgeable 3. Right and ignorant 4. Right and knowledgeable There's also when there's just a disagreement of opinion because you weight the tradeoffs differently, in which case there's less of a right or wrong. The main difference is that in those cases the people involved were in camps 2-4 or simply weighted tradeoffs differently. In this case the author seemed much more clearly in camp 1. Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. Or maybe it would have been hunky dorry. But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). As for Rust-in-Linux, it sounds like your not actually up to date [1]. I'll forgive Ted's emotional volatility at the infamous filesystem talk as he's been much more calm about it now: > There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn. I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. There's going to be resistance and push back and some of it will feel unfair to the Rust folks and some will feel unfair to the C folk and both will be right. [1] https://lwn.net/Articles/991062/ https://lwn.net/Articles/991062/
- jorvi 2y ago
  > But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). I was speaking in general terms, of how recognizable the "heels-in-the-sand" attitude is. In this particular case yes, it does sound right that the current "mseal" proposal / patches is not up to snuff. Edit: also reading through it again, props to Theo's response. Stern but with a lot of edification. > Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. The nice thing about TuxOnIce is that it would have pushed large parts of hibernation into userspace, which would have made it much more versatile and much easier to iterate on. > As for Rust-in-Linux, it sounds like your not actually up to date [1]. One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. How is that "some of it will feel unfair to the Rust folks and some will feel unfair to the C folk"? > I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. [0]https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533
  - vlovich123 2y ago
    I think you really missed what I was trying to say about the hibernate stuff. May be helpful to reread. > One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. I again refer you to the article I linked. The drama has greatly subsided and it seems like people are talking through the differences. While there's some unfortunate intransigence (which may have since been clarified btw), there's also a lot of premature eagerness for pushing Rust into Linux. It's a shame for sure that Wedson burned out and left. If nothing else at least 6 months after that departure the conversation tonally is very very different. > Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job" > Torvalds pointed out that there are kernel features that are currently incompatible with Rust; that is impeding Rust support overall. He mentioned modversions in particular; that problem is being worked on. The list of blocking features is getting shorter, he said, but it still includes kernel features that people need. > Brauner said that nobody has ever declared that the filesystem abstractions would not be merged; the discussion is all about the details of how that will happen. Important to note that the filesystem abstraction conflict is what led to the resignation in the first place. The maintainers are taking a very different position, possibly because of non-public conversations that have happened in the intervening time. > Gleixner said that, 20 years ago, there had been a lot of fear and concern surrounding the realtime kernel work; he is seeing the same thing now with regard to Rust. We cannot let that fear drive things, he said. Torvalds said that Rust has been partially integrated for two years. That is nothing, he said; the project to build the kernel with Clang took a decade, and that was the same old language. > As the session closed, though, the primary outcome may well have been expressed by Torvalds, who suggested telling people that getting kernel Rust up to production levels will happen, but it will take years. It can be frustrating to work on something when the time scale for any kind of observable success can be a decade or more, especially when you see the obstacles as other people on the project. I know I would not have the patience and I'm a huge fan of Rust. Keep in mind that Rust itself isn't actually able to support all the kernel use-cases. There's stuff like which platforms that Rust supports as "tier 1" because the kernel needs to support those platforms - the most likely success case will be having the Rust frontend be able to use GCC as the backend and that work is nowhere near (neither is getting tier-1 automation support for those platforms). Those themselves are years out and so it's understandable that maintainers are trying to figure out how the proposed abstractions will work and how roles and responsibilities will be managed. > They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. I mean it's pretty clear that the goal of the "Rust in Linux" project is to stop having any new C code in the Linux kernel. No one is claiming in 18 months but that's clearly the direction and it shouldn't be surprising for there to be an emotional reaction to that, especially from the maintainers who might perceive that as a threat if they only know C, even if that seems illogical to you. And more importantly, maintainers need to do a lot of work and they hadn't signed up to maintain Rust abstractions so there's another emotional aspect of it where they feel someone else is imposing a new environment on them.
f1shy 2y ago
Every time I see somebody insinuate that all the CVEs would not be there if the kernel was written in Rust, I yawn... The idea that a programming language is a silver bullet is just stupid.
- ArtixFox 2y ago
  who is saying all? pls show me the people who are bruh. its always 70% of the cve's are cuz of things that rust fixes blah blah cmon, lets not lie.
  - f1shy 2y ago
    Would you believe me if I said 65%?
    - ArtixFox 2y ago
      how does that matter? calling 70% ALL is a very funny thing that i can only see on hn

by jorvi 2y ago

vlovich123 2y ago

You can roughly be: 1. Wrong and ignorant 2. Wrong and knowledgeable 3. Right and ignorant 4. Right and knowledgeable There's also when there's just a disagreement of opinion because you weight the tradeoffs differently, in which case there's less of a right or wrong. The main difference is that in those cases the people involved were in camps 2-4 or simply weighted tradeoffs differently. In this case the author seemed much more clearly in camp 1. Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. Or maybe it would have been hunky dorry. But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). As for Rust-in-Linux, it sounds like your not actually up to date [1]. I'll forgive Ted's emotional volatility at the infamous filesystem talk as he's been much more calm about it now: > There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn. I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. There's going to be resistance and push back and some of it will feel unfair to the Rust folks and some will feel unfair to the C folk and both will be right. [1] https://lwn.net/Articles/991062/ https://lwn.net/Articles/991062/

jorvi 2y ago
> But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). I was speaking in general terms, of how recognizable the "heels-in-the-sand" attitude is. In this particular case yes, it does sound right that the current "mseal" proposal / patches is not up to snuff. Edit: also reading through it again, props to Theo's response. Stern but with a lot of edification. > Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. The nice thing about TuxOnIce is that it would have pushed large parts of hibernation into userspace, which would have made it much more versatile and much easier to iterate on. > As for Rust-in-Linux, it sounds like your not actually up to date [1]. One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. How is that "some of it will feel unfair to the Rust folks and some will feel unfair to the C folk"? > I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. [0]https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533
- vlovich123 2y ago
  I think you really missed what I was trying to say about the hibernate stuff. May be helpful to reread. > One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. I again refer you to the article I linked. The drama has greatly subsided and it seems like people are talking through the differences. While there's some unfortunate intransigence (which may have since been clarified btw), there's also a lot of premature eagerness for pushing Rust into Linux. It's a shame for sure that Wedson burned out and left. If nothing else at least 6 months after that departure the conversation tonally is very very different. > Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job" > Torvalds pointed out that there are kernel features that are currently incompatible with Rust; that is impeding Rust support overall. He mentioned modversions in particular; that problem is being worked on. The list of blocking features is getting shorter, he said, but it still includes kernel features that people need. > Brauner said that nobody has ever declared that the filesystem abstractions would not be merged; the discussion is all about the details of how that will happen. Important to note that the filesystem abstraction conflict is what led to the resignation in the first place. The maintainers are taking a very different position, possibly because of non-public conversations that have happened in the intervening time. > Gleixner said that, 20 years ago, there had been a lot of fear and concern surrounding the realtime kernel work; he is seeing the same thing now with regard to Rust. We cannot let that fear drive things, he said. Torvalds said that Rust has been partially integrated for two years. That is nothing, he said; the project to build the kernel with Clang took a decade, and that was the same old language. > As the session closed, though, the primary outcome may well have been expressed by Torvalds, who suggested telling people that getting kernel Rust up to production levels will happen, but it will take years. It can be frustrating to work on something when the time scale for any kind of observable success can be a decade or more, especially when you see the obstacles as other people on the project. I know I would not have the patience and I'm a huge fan of Rust. Keep in mind that Rust itself isn't actually able to support all the kernel use-cases. There's stuff like which platforms that Rust supports as "tier 1" because the kernel needs to support those platforms - the most likely success case will be having the Rust frontend be able to use GCC as the backend and that work is nowhere near (neither is getting tier-1 automation support for those platforms). Those themselves are years out and so it's understandable that maintainers are trying to figure out how the proposed abstractions will work and how roles and responsibilities will be managed. > They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. I mean it's pretty clear that the goal of the "Rust in Linux" project is to stop having any new C code in the Linux kernel. No one is claiming in 18 months but that's clearly the direction and it shouldn't be surprising for there to be an emotional reaction to that, especially from the maintainers who might perceive that as a threat if they only know C, even if that seems illogical to you. And more importantly, maintainers need to do a lot of work and they hadn't signed up to maintain Rust abstractions so there's another emotional aspect of it where they feel someone else is imposing a new environment on them.

f1shy 2y ago

Every time I see somebody insinuate that all the CVEs would not be there if the kernel was written in Rust, I yawn... The idea that a programming language is a silver bullet is just stupid.

ArtixFox 2y ago
who is saying all? pls show me the people who are bruh. its always 70% of the cve's are cuz of things that rust fixes blah blah cmon, lets not lie.
- f1shy 2y ago
  Would you believe me if I said 65%?
  - ArtixFox 2y ago
    how does that matter? calling 70% ALL is a very funny thing that i can only see on hn