Rust in the FreeBSD kernel

[msplsh]

How is a random architecture's maintainer supposed to come up with a Rust toolchain in 6 months

Big ask with no warning. Kind of rude, really. A bit odd that one guy can leverage a key component this way?

 

[cracauer@]

Big ask with no warning. Kind of rude, really. A bit odd that one guy can leverage a key component this way?

I am surprised by that, too.

Now I imagine Debian ended up with systemd in a similar way.

 

[T-Aoki]

I am surprised by that, too.

Now I imagine Debian ended up with systemd in a similar way.

If I recall correctly, Ubuntu is based on Debian.
So it could be Ubuntu (Canonical)'s will to do so, to minimize their effort to develope Ubuntu.

 

[bakul]

Might be worth creating a "Linux" forum so that all linux related discussions can be corralled there. Sorta like The Unix-Haters Handbook

 

[T-Aoki]

Might be worth creating a "Linux" forum so that all linux related discussions can be corralled there. Sorta like The Unix-Haters Handbook

Even if doing so, things like "run Linux on Bhyve", "run Linux on emulators/something" and "porting Linux apps to FreeBSD" would remain here.

 

[bakul]

Even if doing so, things like "run Linux on Bhyve", "run Linux on emulators/something" and "porting Linux apps to FreeBSD" would remain here.

As long as there is a FreeBSD/bhyve/linux emulation connection, that is fine and in fact should have a place other than off-topic! But may be discussing the finer points of systemd and other such linux specific stuff can go in a linux forum!

 

[cracauer@]

Sorry for the Linux excursion. It was Rust triggered and I went WTF on the social aspect of that message.

To get back on the Rust topic, I wonder how the different Rust toolchains for kernel and apt will be managed.

 

[T-Aoki]

But may be discussing the finer points of systemd and other such linux specific stuff can go in a linux forum!

Just an idea (not sure possible / meaningful enough or not), but "Implement BSD-licensed systemd emulator to be startup from rc.d scripts" could be a candidate for kinda GSoC to ease porting interesting new softwares?

If implemented in /bin/sh and parts of helpers in C, base would be the place for it. But if implemented in something NOT in base, ports would be the place for it (except codes for tests like /usr/src/tests and /usr/tools/test only).

If Rust becomes official part of LLVM project itself, and defaulting cdylib (which Rust guys would hate) as its object linking style, Rust in base would be far more realistic than now. I feel it unlikely, though.

 

[bakul]

There seem to be FUDs (i.e., by US gov.) that all projects SHALL switch to memory-safe languages.

This is what the DoD says: https://media.defense.gov/2025/Jun/...RABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF

Excerpt:

The goal of these documents is to strengthen national cybersecurity by reducing memory-related vulnerabilities, which requires more than developer discipline and best practices. Achieving better memory safety demands language-level protections, library support, robust tooling, and developer training. While decades of experience with nonMSLs have shown that secure coding standards and analysis tools can mitigate many risks, they cannot fully eliminate memory safety vulnerabilities inherent to these languages as effectively as the safeguards used in MSL.
...
MSLs such as Ada, C#, Delphi/Object Pascal, Go,Java, Python, Ruby, Rust, and Swift offer built-in protections against memory safety issues, making them a strategic choice for developing more secure software.

So not just Rust and not really FUD + it is a guide/recommendation for (presumably govt controlled) critical infrastructure software, not "all projects" as you say. AFAIK this is still being discussed and not a requirement to sell your software to the govt entities. Quoting more:

Conclusion
Memory vulnerabilities pose serious risks to national security and critical infrastructure. MSLs offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability. Adopting MSLs can accelerate modern software development and enhance security by eliminating these vulnerabilities at their root.

The report is worth reading, especially the "open questions and study areas" section.

While their goal is admirable, it is just not realistic to rewrite everything in memory safe languages. Nor is memory safety sufficient.

 

[blackbird9]

Ubuntu Will Use Rust For Dozens of Core Linux Utilities - Slashdot

Ubuntu "is adopting the memory-safe Rust language," reports ZDNet, citing remarks at this year's Ubuntu Summit from Jon Seager, Canonical's VP of engineering for Ubuntu: . Seager said the engineering team is focused on replacing key system components with Rust-based alternatives to enhance...

news.slashdot.org

Interesting thread on this subject. Some of the comments say that one of the motivations for ubuntu doing the rewrite in rust is to replace GPL C code with non-GPL rust code, and suggests IBM ("dead rat") is doing the same thing. Removing the GPL makes it (much) easier to monetize the software, of course. If I can believe the comments, the billionaire behind ubuntu is pushing rust for this reason (and why it's being pushed back up into debian). So there may be commercial reasons for this shift as well. I'm sure ubuntu and IBM want to monetize their investment in linux. This reason actually makes sense from a business POV if your objective is to screw more profit out of linux, but of course at the cost of technical degradation (they've already broken automatic updates in ubuntu), but since when did they ever give a damn about that. They mention that the rust developers doing the coreutils rewrite are not allowed to look at the existing coreutils C code, which means that it's a clean-room rewrite using the manpages as the 'spec' (sic); so that they (the rust developers) are not 'contaminated' by the GPL C code.

So squeezing out GPL code in order to monetize linux more effectively might be a real reason that we have missed in our discussion so far; any 'security gains" would then be incidental to the real motivation, which is to increase business profits. Of course "security gains" is how you sell it, whether they are real or fictional.

 

[cracauer@]

Ubuntu Will Use Rust For Dozens of Core Linux Utilities - Slashdot

Ubuntu "is adopting the memory-safe Rust language," reports ZDNet, citing remarks at this year's Ubuntu Summit from Jon Seager, Canonical's VP of engineering for Ubuntu: . Seager said the engineering team is focused on replacing key system components with Rust-based alternatives to enhance...

news.slashdot.org

Interesting thread on this subject. Some of the comments say that one of the motivations for ubuntu doing the rewrite in rust is to replace GPL C code with non-GPL rust code, and suggests IBM ("dead rat") is doing the same thing. Removing the GPL makes it (much) easier to monetize the software, of course. If I can believe the comments, the billionaire behind ubuntu is pushing rust for this reason (and why it's being pushed back up into debian).

If they push it back up into Debian it would be public again.

But generally, a large part of organizations using FreeBSD are GPL haters.

 

[kpedersen]

But generally, a large part of organizations using FreeBSD are GPL haters.

Where I work, the organisation (and our clients) dislike GPL due to Defcon 703.
Whereas the individual developers dislike GNU due to the mess and noise.

(We generally favour the Apache license due to it protecting against potential patent encumberment further down the road, I don't quite understand).

 

[Zare]

This is absurd, I ain't running Linux without the FSF part.

 

[rbranco]

If they push it back up into Debian it would be public again.

But generally, a large part of organizations using FreeBSD are GPL haters.

I don't think hatred is what drives most people and even organizations. There are valid technical reasons to use FreeBSD that are not related to the licenses.

Most of the push for Rust+MIT is ideological, though. They do hate the FSF because of Richard Stallman.

 

[blackbird9]

I don't think hatred is what drives most people and even organizations. There are valid technical reasons to use FreeBSD that are not related to the licenses.

Most of the push for Rust+MIT is ideological, though. They do hate the FSF because of Richard Stallman.

I don't think the evangelist idealogues are very important. The important people are the ones making the investment decisions, as to where the billions of dollars gets spent. Someone is funding those rust evangelists after all, they haven't come from nowhere, and they have to eat too. We saw all this same kind of push in the late 90s with Java, I remember being told the same thing around 1997, C was going to be "legacy" and Java (or c#/managed code) was going to replace it wholesale. That didn't work out, for various reasons.

In a commercial firm, having to deal with the GPL can be a nightmare for your IP and bottom line. That was always the problem for companies trying to get a free ride from embedding linux into their products, and avoiding the costs of paying for a commecial operating system. You might have to open some of your code and expose your trade secrets; or try to partition off the parts you don't want to open from the code that is 'contaminated'. I guess using a completely different language (from C/C++) and MIT license makes the separation really clear. I wonder if they are thinking of merging linux and the MS-windows kernel longer term too, but that is just speculation on my part; I have noticed over the years that MS often seems to be involved in many of the changes in linux, one way or another.

Quite whether linux will end up with the FSF code squeezed out remains to be seen. Mainstream linux is almost unrecognisable now, since ibm/red hat/ubuntu got hold of it and added all their junk into it, compared to how it used to be when I used to run slackware. Perhaps linux will fork again, who knows. Anyhow, I thought that thread was interesting because it discusses what might be some of the real business reasons behind the push for rust. The baloney about it's all going to be more secure might be just a sales line. Well, true, it's not all baloney, rust does have some security advantages I'm sure; but mixing rust and C in the same codebase is a recipe for trouble. Personally I hope that freebsd doesn't go down that route.

 

[fmc000]

Perhaps linux will fork again, who knows.

Linux (the kernel) is GPL2 only. Even after a fork it will remain GPL2.

The userspace part can be rewritten in a more permissive license so that it can eventually be made closed source (and it will be eventually forked again, making the point moot).

In short, "molto rumore per nulla" as we say in Italy. But conspiracy theories are fun and they generate clicks, so....

 

[T-Aoki]

Well, true, it's not all baloney, rust does have some advantages I'm sure; but mixing rust and C in the same codebase is a recipe for trouble.

So Rust is not at all for existing projects with small community and large codehase mainly written in C (with some asm) like FreeBSD.

In these cases, if anyone want to introduce new languages (not limited with Rust), it is mandatory to mix-up the new language, C and asm.
So I strongly stick with the idea that new language should be compiled into C (if needed, with asm codes to handle additional interfaces), then, compiled and linked with existing (not rewritten) C and asm codes.

Of course, I don't deny brand-new projects to be written in Rust, though.

 

[T-Aoki]

But generally, a large part of organizations using FreeBSD are GPL haters.

Or having to use NDA'ed codes in conjunction with their codes.
It clearly disallows to be (at least statically) linked with GPL'ed codes, or at least written based on GPL'ed codes, as it mandates them to disclose NDA'ed part of 3rd party codes. Legally impossible.

 

[T-Aoki]

This is what the DoD says: https://media.defense.gov/2025/Jun/...RABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF

Excerpt:


So not just Rust and not really FUD + it is a guide/recommendation for (presumably govt controlled) critical infrastructure software, not "all projects" as you say. AFAIK this is still being discussed and not a requirement to sell your software to the govt entities. Quoting more:


The report is worth reading, especially the "open questions and study areas" section.

While their goal is admirable, it is just not realistic to rewrite everything in memory safe languages. Nor is memory safety sufficient.

What DoD "wrote" is sane, in my humble opinion.
But people around there (Rust lobbyists?) and mis-understood people does.

 

[rbranco]

I don't think the evangelist idealogues are very important. The important people are the ones making the investment decisions, as to where the billions of dollars gets spent. Someone is funding those rust evangelists after all, they haven't come from nowhere, and they have to eat too. We saw all this same kind of push in the late 90s with Java, I remember being told the same thing around 1997, C was going to be "legacy" and Java (or c#/managed code) was going to replace it wholesale. That didn't work out, for various reasons.

Java still rules in enterprise settings.

In a commercial firm, having to deal with the GPL can be a nightmare for your IP and bottom line. That was always the problem for companies trying to get a free ride from embedding linux into their products, and avoiding the costs of paying for a commecial operating system. You might have to open some of your code and expose your trade secrets; or try to partition off the parts you don't want to open from the code that is 'contaminated'. I guess using a completely different language (from C/C++) and MIT license makes the separation really clear. I wonder if they are thinking of merging linux and the MS-windows kernel longer term too, but that is just speculation on my part.

I don't think that's they main excuse to rewrite to Rust. Android uses OpenBSD's libc.

Quite whether linux will end up with the FSF code squeezed out remains to be seen. Mainstream linux is almost unrecognisable now, since ibm/red hat/ubuntu got hold of it and added all their junk into it, compared to how it used to be when I used to run slackware. Perhaps linux will fork again, who knows. Anyhow, I thought that thread was interesting because it discusses what might be some of the real business reasons behind the push for rust. The baloney about it's all going to be more secure might be just a sales line. Well, true, it's not all baloney, rust does have some security advantages I'm sure; but mixing rust and C in the same codebase is a recipe for trouble. Personally I hope that freebsd doesn't go down that route.

Linux is only the kernel and it's GPLv2.

 

[blackbird9]

Yes Java won in some quite large niches, it wasn't a complete failure, mainly due to ibm's backing. It will be interesting to see how it comes out in the wash. I wonder if parts of the linux kernel are re-written in rust, will they still be GPL2. But then it wouldn't be 'linux' any more, would it? Anyhow, the next 10 years or so should be interesting.

 

[cracauer@]

I assure you there are companies with lawyers that rule out use of GPLed code when other companies do not. Legal intepretations just come out differently every now and then.

 

[blackbird9]

Yes, none of it is black and white. A lot depends on whether you've got a big patent portfolio you can threaten other companies with to back you up.

 

[Zare]

I don't think it is necessary good to have #1 software as BSD/MIT or any totally permissive license. Because the vendor behind it can embrace/extend/extinguish the complete project. Sort of what's happening to GNU/Linux under 'patronage' of Red Hat Inc.

In BSD world such an affair works because BSDs are technology in form of OS, and the vendors who fund the Foundation use it for the technology, and anything they commit back can be usable by FreeBSD users, if not usable at least not a nuisance.

There is no such thing in desktop OS world, the funders are companies who dabble in advertising, broadcast media, steal user data for revenue streams and expect OS under their 'ownership' to perform the dirty work for them. Even using so called dark UI patterns. If tomorrow such entities started funding FreeBSD in enough quantity to skew the development to their direction, FreeBSD would become Windows 11 in under a decade.

For that reason I believe it is important to block such attempts politically via licensing and that is what FSF has tried to do.