6 ms·

It’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about

It’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about a kernel maintainer complaining about Rust and Linus refusing to actually apply any sort of rules to the maintainers. It just seems very aimless and unfocused.

giancarlostoro 2y ago
My guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.
- baq 2y ago
  Unfortunately it won’t matter if the C and only C developers block generic language interoperability interfaces…
- geodel 2y ago
  > someone needs to step up and be the Linus of Rust code for Linux No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
  - mappu 2y ago
    Such new OS exists already (Redox). It's actually really good and can run modern DEs (Cosmic) and some recent commercial games (Balatro). The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux. To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
    - ChocolateGod 2y ago
      > To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option. Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
      - aw1621107 2y ago
        Probably depends on what exactly you're looking for in a viable solution. Zig does not provide the same level of memory safety as Rust does (IIRC it doesn't protect against data races and doesn't offer (complete?) temporal memory safety), so if what Rust provides is the bare minimum you want Zig won't cut it.
  - baq 2y ago
    OS part is easy, there's an OS behind every other sofa in your closest university with software engineering classes. Getting people to write drivers for it is the hard part. Most OSes never boot outside of qemu.
fweimer 2y ago
Most development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised. Writing policies hard, and the environment here is somewhat challenging.
- TheCleric 2y ago
  I agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.
dyingkneepad 2y ago
> It’s all open source and therefore mostly unpaid volunteer driven The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies. Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/ https://lwn.net/Articles/1004998/
sunshowers 2y ago
It's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.
progmetaldev 2y ago
I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language. From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code). I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks. Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.
- timeon 2y ago
  > From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code). This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?
bitwize 2y ago
Despite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development. The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.
okanat 2y ago
The people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.

giancarlostoro 2y ago

My guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.

baq 2y ago
Unfortunately it won’t matter if the C and only C developers block generic language interoperability interfaces…
geodel 2y ago
> someone needs to step up and be the Linus of Rust code for Linux No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
- mappu 2y ago
  Such new OS exists already (Redox). It's actually really good and can run modern DEs (Cosmic) and some recent commercial games (Balatro). The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux. To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
  - ChocolateGod 2y ago
    > To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option. Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
    - aw1621107 2y ago
      Probably depends on what exactly you're looking for in a viable solution. Zig does not provide the same level of memory safety as Rust does (IIRC it doesn't protect against data races and doesn't offer (complete?) temporal memory safety), so if what Rust provides is the bare minimum you want Zig won't cut it.
- baq 2y ago
  OS part is easy, there's an OS behind every other sofa in your closest university with software engineering classes. Getting people to write drivers for it is the hard part. Most OSes never boot outside of qemu.

fweimer 2y ago

Most development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised. Writing policies hard, and the environment here is somewhat challenging.

TheCleric 2y ago
I agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.

dyingkneepad 2y ago

> It’s all open source and therefore mostly unpaid volunteer driven The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies. Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/ https://lwn.net/Articles/1004998/

sunshowers 2y ago

It's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.

progmetaldev 2y ago

I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language. From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code). I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks. Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.

timeon 2y ago
> From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code). This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?

bitwize 2y ago

Despite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development. The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.

okanat 2y ago

The people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.