As a lover of Rust, ooo boy does this sound like a bad idea. The Rust compiler is not guaranteed to always output safe code against malicious inputs given that there’s numerous known soundness bugs that allow exploiting this. Unless I’m missing something this is a security nightmare of an idea.
Also there’s reasons why eBPF programs aren’t allowed to run arbitrarily long and this just ignores that problem too.
> We currently do not support unprivileged use case (same as BPF). Basically, Rex extensions are expected to be loaded by privileged context only.
As I understand it, in privileged context would be one where one is also be able to load new kernel modules, that also don't have any limitations, although I suppose the system could be configured otherwise as well for some reasons.
So this is like a more convenient way to inject kernel code at runtime than kernel modules or eBPF modules are, with some associated downsides (such as being less safe than eBPF; the question about non-termination seems apt at the end of the thread). It doesn't seem like they are targeting to actually put this into mainstream kernel, and I doubt it could really happen anyway..
It’s a common HN trope to generalise a “community” based on a handful of people or even just one person. “See this is why I dislike the xyz community”, says a person justifying their confirmation bias.
Perhaps the world is too complex without breaking it down into in-groups and out-groups, with any out-groups supposedly being completely homogenous. Pretty intellectually lazy but fairly common on HN, to the point where it’s not even worth calling out.
You may be correct but pjmlp is not one of those and if you had been here long enough you would have known that. You're the one creating an in-group here and putting yourself on the 'good' side. Perhaps that is too complex for you but I think it is intellectually lazy not to get who you're referring to before making comments such as these. Note that your strawman "See this is why I dislike the xyz community" wasn't part of this thread at all.
One could also say some in the C or C++ communities actually care about security, thus no need for Rust or alike, yet no one is paying attention to those small groups in the corner.
A village is judged by its population actions, and even the black sheeps count to its overall image from outsiders.
Indeed. If there is one person here that keeps their footing in language debates it is you (and I'm always blown away with how many details you have at instant recall that I never realized were there). So thank you for the lessons over the years, it has helped me evaluate my choices better.
As for that sentence: I think Rust has its place, I do not agree at all with their 'rewrite' mantra because there are a ton of risks associated with rewrites that have nothing to do in what language the code is written in, just that it is a rewrite.
I think the Rust folks should go all-in on Redox and fix their tool optimization issues. And do one thing and do that well rather than to be the next Swiss army knife of programming. And I also think that the C and C++ folks can do a lot better still. Filip is doing something interesting I think and if there a practical solution to the C heritage I think it lies more in his direction than in rewriting billions of lines of battle tested code. Performance isn't nearly as important as it used to be. Another thing that I think would be beneficial would be to take as many device drivers out of the linux kernel as possible and run them as userspace processes.
Anyway, belated Merry Christmas to you and a pre-emptive happy 2026!
Also there’s reasons why eBPF programs aren’t allowed to run arbitrarily long and this just ignores that problem too.
If it has to be native code, it should live on user space, at very least.
> We currently do not support unprivileged use case (same as BPF). Basically, Rex extensions are expected to be loaded by privileged context only.
As I understand it, in privileged context would be one where one is also be able to load new kernel modules, that also don't have any limitations, although I suppose the system could be configured otherwise as well for some reasons.
So this is like a more convenient way to inject kernel code at runtime than kernel modules or eBPF modules are, with some associated downsides (such as being less safe than eBPF; the question about non-termination seems apt at the end of the thread). It doesn't seem like they are targeting to actually put this into mainstream kernel, and I doubt it could really happen anyway..
Maybe i'm missing something, but isn't that a bad thing?
Why judge the whole Rust community for the choices made by one minor subgroup?
Rust Striking Force meme exists for a reason, their actions are also not supported by the core team.
Perhaps the world is too complex without breaking it down into in-groups and out-groups, with any out-groups supposedly being completely homogenous. Pretty intellectually lazy but fairly common on HN, to the point where it’s not even worth calling out.
One could also say some in the C or C++ communities actually care about security, thus no need for Rust or alike, yet no one is paying attention to those small groups in the corner.
A village is judged by its population actions, and even the black sheeps count to its overall image from outsiders.
As for that sentence: I think Rust has its place, I do not agree at all with their 'rewrite' mantra because there are a ton of risks associated with rewrites that have nothing to do in what language the code is written in, just that it is a rewrite.
I think the Rust folks should go all-in on Redox and fix their tool optimization issues. And do one thing and do that well rather than to be the next Swiss army knife of programming. And I also think that the C and C++ folks can do a lot better still. Filip is doing something interesting I think and if there a practical solution to the C heritage I think it lies more in his direction than in rewriting billions of lines of battle tested code. Performance isn't nearly as important as it used to be. Another thing that I think would be beneficial would be to take as many device drivers out of the linux kernel as possible and run them as userspace processes.
Anyway, belated Merry Christmas to you and a pre-emptive happy 2026!
(I may come across as an Ada zealot myself.)