210
Linux 7.0 Officially Concluding The Rust Experiment (www.phoronix.com)
submitted 9 months ago by to c/linux@programming.dev
57 comments fedilink hide all child comments
 

While Linux 7.0 is the next kernel version solely over Linus Torvalds' numbering preference, there is a notable symbolic change that was sent in overnight for this new kernel merge window: formally concluding the "Rust experiment" with upstream kernel developers now in acceptance that Rust for the Linux kernel is here to stay.

The patch was talked about back in December that the Rust experiment is over and it's here to stay. There are already uses for Rust in production environments, some Linux distributions shipping with Rust kernel code, and millions of Android devices also using it.

you are viewing a single comment's thread
view the rest of the comments
[–] 39 points 9 months ago (27 children)

Can someone explain to me why Rust has been so controversial for the GNU/Linux kernel? One thing that I personally don't like is that the equivalent Rust-made (equivalent) GNU tools are licensed under MIT (or Apache? - something permissive like that) instead of GPL. If they were under GPL, I'd be more than happy. But since the kernel is under GPL regardless of C or Rust, what is the reason for the backlash? Sounds like a very promising language indeed.

  • permalink
  • fedilink
  • source
  • hideshow 27 child comments
    •
  • [–] 38 points 9 months ago* (last edited 9 months ago) (1 child)

    Most common reason I saw was not wanting mixed languages across the code base.

    If you're a Rust maintainer and you're given a C patch (or reverse) then what do you do with it/confirm it's not bringing other bugs.

    Other issues are that it's heavier, hurts compatibility, and doesn't function like C.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 18 points 9 months ago

    The main real argument is that if new contributors write code and then leave for other projects then old contributors still have to maintain that code, a task that gets really hard when code is written in a different paradigm entirely.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 11 points 9 months ago (2 children)

    From the perspective of somebody who's actually hacked on Linux: Most Linux maintainers, like most programmers in general, are full of machismo stemming from the inherent difficulty of writing C. It is extremely difficult to write correct C and nobody can do it consistently, so those maintainers are heavily invested in the perception that they are skilled with C. Rust is much easier to write and democratizes kernel hacking, which is uncomfortable for older maintainers due to the standard teenagers-vs-parents social dynamics. Worse, adapting various kernel interfaces so that they are Rust-friendly has revealed that the pre- and postconditions of interface methods were not known before; there is existing sloppiness in the kernel's internals which is only visible because of Rust-related cleanups.

    Note that Linux is not a GNU project. GNU's kernel project is GNU Herd. "GNU/Linux" refers to Linux userlands populated with GNU packages. It's important not to be distracted by this; the kernel is agnostic towards userland and generally is compatible with any loadable executable that uses Linux's public syscall interface, so the entire discussion of Rust in the kernel is separate from anything going on in userland.

    Most siblings are wrong! PRs written in Rust can be rejected. There are already multiple non-C languages in the kernel. Rust is sufficiently available on the platforms where it will be required for building kernel. Maintainers are only added after they have shown themselves to be socially reliable and they can be removed by other maintainers if they are unresponsive. The only correct sibling points out that Rust is different.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 8 months ago (1 child)

    There are already multiple non-C languages in the kernel

    Such as? Apart from C and Assembly.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 8 months ago

    @pressanykeynow @Corbin There is some python in the build infrastructure.But this is the real reason for the push-back against Rust: it is something else that everybody involved has to learn, and that means diluting the extreme expertise in C that makes the kernel so good.In a distant nirvana, there will be no C left, only Rust, and then all developers can really drill down on that.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 9 months ago (14 children)

    What's the advantage of GPL? As far as I'm aware MIT and Apache are both FOSS. But I'm new to this and still learning.

    I don't know what the big deal about Rust is. It seems like a cool language to me...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 27 points 9 months ago (7 children)

    GPL enforces that all derivatives are FOSS and GPL as well. With permissive licenses, like MIT and Apache, a company is free to take the code, change/develop it further (or leave it as is) and make it closed-sourced without sharing anything with anyone. Regarding Rust, I am with you. Hence my question.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 4 points 9 months ago (6 children)

    I see. That makes sense.

    So if the kernel were written in a language licensed under GPL, for instance, Ubuntu would either have to ditch their proprietary blobs or make their own kernel?

    If I had to guess, the only reason Rust might be controversial to some people is probably because they're used to C and likely set in their ways. Someone who's been programming since the 80s and doesn't want to learn a new language cause maybe they'll feel like a newbie again and can't be smug about knowing every possible command in C anymore. Just a guess...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 8 points 9 months ago (4 children)

    I'm pretty sure that code written in any language can be licensed under the GPL. That's why I cannot understand the backlash against Rush for the Kernel.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] -1 points 9 months ago (3 children)

    I don't understand the backlash against using an MIT/Apache licence at all. Those licenses are far more permissive than GPL but completely compatible.

    The only downside is that someone could fork the code and close source it, but the original code still remains available and that's where the community will stay.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 11 points 9 months ago

    A lot of things can go wrong. A company can take the free code, change it slightly to work only with a proprietary file type and then use their resources to promote their version and make their proprietary filetype and proprietary program the industry standard. Unfortunately this sounds too familiar. There are even cases that the filetype is an open standard but obfuscated to make it impossible for anyone (including the original FOSS) to open/save it.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 7 points 9 months ago* (last edited 9 months ago)

    It's pretty much undeniable that the GPL has been a massive driving force behind companies giving back to projects, and it's similarly undeniable that MIT-licensed projects have fewer comparable contributions.

    Sure, the community can stay on the open version, but it will still be companies mostly taking without giving back.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 9 months ago

    Iirc GPL is how we have OpenWRT. Because a company used Linux in their routers, but forgot to release the code initially until sued by FSF or whomever.

    Imagine, for example, that your phone has forks of Linux utilities with mysterious closed-source functionality added here and there. And you'd need to reverse-engineer that functionality to have LineageOS and such, instead of just taking the source-code.

    Proprietary apps are prone to enshittification, and permissive licenses allow vendors to build their proprietary software on open-source software without giving anything in return.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 9 months ago* (last edited 9 months ago)

    The kernel is licensed under GPL, specifically only version 2. And it can't be relicensed, since it contains code from many people. The poster above is complaining about command-line utilities that are being rewritten in Rust.

    Binary-only modules can be used with the kernel, because they don't use the kernel's source, only the API or a GPL middleware is made that is compiled with kernel header files, but provides an intermediary API for the binaries. I'm not quite versed in what exactly is allowed and prohibited by GPL.

    Edit: Linux-syscall-note explicitly places the boundary of 'derivative works' at syscalls — so userspace programs aren't considered derivative and don't have to be licensed under GPL, but kernel modules are.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 8 months ago (2 children)

    What's the advantage of GPL?

    See the state of Linux used and contributed back to by corporations and FreeBSD used but not contributed to by corporations.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 9 months ago

    From what I have ready the issue is as follows:

    Rust is a memory safe language, because of this Rust enthusiast have been pushing for it. Not a problem there.

    The issue is that some have taken it to an extreme, evangelical level where they expect name dropping Rust should open every door and blindly accept every PR

    In reality, Rust rewrites can (and have) introduced bugs because you can make shitty code even with the best languages out there

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (1 reply)