Rust in the FreeBSD kernel

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!
 
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.
 
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.
 
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.
 

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.
 

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.
 
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).
 
Back
Top