what we can do with rust is beyond what we can imagine

well there is already and can be used, I will have an idea. many here still said that I don't have the competence for that. and this my friends is what we will see
 
many here still said that I don't have the competence for that.
Unless I'm begin unintentionally oblivious here I don't think that anybody stated that you don't have the competence.
I think the intention was to communicate that these things usually require demonstration & proof-of-concepts to elevate a discussion from this from the current state to something more concrete that can be objectively evaluated.

Everybody in this topic/thread that you created appears to be participating in this discussion willingly - which is a good thing! :)
Sometimes, brevity can be easily mistaken for offensive statements. Hence my posts are usually a bit longer than the average on this forum :D

Thank you for sharing that FreeBSD kernel module written in Rust! Not something I would have actively searched for, but something I'd definitely want to check out!
 
Requirements:
  • FreeBSD machine
  • Rust nightly
  • Xargo
I recommend using rustup for installing and handling different versions of Rust.
It will need the compiler because of the package/port, even if the compiler isn't needed and only Cargo is in the actual use. Come to think of it, compiling the kernel in C is a common user task for FreeBSD users. Compiling, rather than inserting code, would obviously need the Rust compiler.

As long as it can be used with existing kernel drivers written in C, which is likely. So much code like graphics modules is necessary for many people's uses, that will take too much to be written in another language as it's taken a long time for those to develop.

That's a project that Dimitri Chuikov can contribute to, and add Documentation, including a Howto, on how to use it.

Imagine if the FreeBSD kernel in Rust were used in https://www.minibsd.org/, which is a 16 MB FreeBSD fork. That would be halfway towards a whole new operating system.
many here still said that I don't have the competence for that.
I saw criticism of the idea, but I don't know if anyone said that. I don't have the ability to do lots of things which are complex and require a specific knowledge set.

I see criticism of ideas a lot, while I don't get offended by them, I get frustrated with my interpretation of them as people defaulting to, "you can't do this," "you can't do that", which seems like being stuck in a loop for what is or may be better. But, it turns out that Rust as a FreeBSD kernel module is a project that has been done before.

It's good that the project was found for those who like to try it. And it's good that the link to it and the thread will bring attention to it. It's fitting for the forum. It would be great to see its implementation be discussed in the near future as well. It would be cool to see and learn how that runs.
 
I'm a committer and love rust for the two features it advertises most often: memory safety through the borrow checker and fearless concurrency. These are two error classes C is particularly vulnerable to that become non-issues with rust. That's a HUGE thing. If a fairy granted me a wish for the successor of C, it would be rust.

But I wouldn't hold my breath for seeing rust in the kernel. Datapoint being Linux, which ages ago tried to at least compile kernel code in C++ mode, expecting "better type safety" or other vagueness. That initiative failed for reasons I'm too lazy to dig up.
Then you need to convince a lot of smart people to invest time learning a new language. Rust is quite different from C, and if you're like me, never touched java or C++ because C is good enough, then maybe C is actually good enough for the FreeBSD kernel. And if it ain't broke, why fix it?
 
I don't like that two separate compilers would be needed, even if both are on top of the same LLVM. In the short term, we have that anyway. The base has its own compiler which (for most) comes in binary, then some ports always ask for a newer compiler version for C, sometimes asking for multiple versions of LLVM/C. The code in Rust would be faster and have improvements which would have an inconvenience of coming with two compilers, but those compilers would otherwise not have an effect on the speed of the code. If it were forked from MiniBSD, that would be a whole new operating system, which would rely on only 1 compiler chain for the base.

I would like to see discussions and experiences on here about the implementation of a Rust Kernel used in FreeBSD or any FreeBSD derivative.

The latest updates of the code of Echo (Rust kernel for FreeBSD) are 5 years old. It looks like a surge of interest in it can help with it getting patches and other updates.

Also, note from the Echo website:
Warning
If there are any bugs or faulty code the kernel will most likely hang.
I recommend testing the module in a virtual machine.
It keeps your system safe and it makes it easier to develop and test.

Note from Redox-OS website, which is a completely different project than Echo:
  • Custom libc written in Rust (relibc)
That Rust has its own implementation of libc. Relibc seems to have its own problems:
 
The latest updates of the code of Echo (Rust kernel for FreeBSD) are 5 years old. It looks like a surge of interest in it can help with it getting patches and other updates.
Echo is just a PoC for writing a kernel module in Rust, not the kernel itself. Doesn't need updates unless it doesn't work anymore.

Also the warning is basically for people who don't know that screwing up in kernelspace means Game Over.
 
It's occurred to me, the Rust Kernel software for FreeBSD is 3 to 5 years old. Which FreeBSD version kernel did it work with? Would an older Rust kernel or this program work with a newer FreeBSD, or perhaps with all of the other kernel modules and parts of the base system? Echo is a kernel module that builds a Rust kernel based on a newer FreeBSD and kernel?

MiniBSD is also old from 2016. Though, it's a set of scripts to reduce the size of a FreeBSD system to a MiniBSD system. I thought it was an actual iso install of that full system. The tiny OS may lack the tools to build/install a Rust kernel.


Back up kernels is what I have on my system, with the bootloader to select from them on reboot, which is handy in the case of a kernel crash. Even if it means keeping at least 1 original working kernel in C. Perhaps manually copying them in, if there's no backups on a system.

/boot/loader.conf:
Code:
kernels="kernel kernel.old kernel.orig kernel.bk kernel.c kernel.rust"
kernel= "kernel" # default selection kernel
kernel.old always gets replaced, so can't be always dependable for a sure backup. The last one installed will become kernel. These kernel directories can be copied to new directories of a corresponding descriptive name. kernel.bk can be one in C of the original one of the FreeBSD version, or of one saved from any freebsd-update that works. The latest compiled Rust or C kernel can be chosen on each bootup as well. This menu can also be used to test performance of a compiled Rust vs C kernel on a different reboot.
 
Echo is a kernel module that builds a Rust kernel based on a newer FreeBSD and kernel?
I don't think that this is correct. The echo GitHub repository initially linked by Dimitri Chuikov appears to be "just" a kernel module. It's not a kernel. It's just a kernel module. Just like you'd write a FreeBSD kernel module in C except that this one is written in Rust.
 
Since you liked it tha much:
I got it from


which actually is a link on Colin Percival's website, who's (as you all already know :cool:) member of FreeBSD's Primary RE Team (security I think.)
 
… member of FreeBSD's Primary RE Team (security I think.)

<https://www.freebsd.org/administration/#t-re> shows Colin Percival as Deputy Lead within the Primary Release Engineering Team. <https://people.freebsd.org/~cperciva/> leads to security-specific <https://people.freebsd.org/~cperciva/funding.html>, and <https://www.daemonology.net/>.

Recent comments in /r/freebsd include <https://old.reddit.com/comments/s67ymv/-/i8utndz/?context=1> about the ESP for 13.1-RELEASE; <https://old.reddit.com/comments/ut1dd6/-/i98s5my/> about Sony; and <https://old.reddit.com/comments/ur65ph/-/i9ekbj5/?context=1>, which led to FreeBSD bug 264113 – FreeBSD 13.1-RELEASE Installation Instructions: update
 
just my 2 cents here, but last time I looked at Redox-OS, it seemed to be a 'proof-of-concept' work. The only proper screenshots that I could find - they were in a VM. The rest were photographs of laptops running Redox-OS.

I like some ideas put forth by Rust (memory safety and security), but rust-crates seem to be another case of reinventing the wheel (think Perl modules or Python modules). C/C++ libs (or Ruby libs, for that matter) are a similar idea. Code re-use is a nice idea, but in practice, it may not be that practical. 😑
 
When Rust first came out, years ago, I pooh'ed it saying it was "not another language to save us all". Then took the time to study it and changed my mind remarking, "There's something to this after all. I kind of like it!" but never found the time or need to learn more. As time went on, I hear, more and more lately, about the steep learning curve. And now they added something to make life more difficult, iirc.

No longer do I see people recommending Rust as their goto language. Always keep things as simple as possible. For me, that's C.
 
Hello when I mentioned that rust can give us a good programming base I said in the way we can implement things, I see the FreeBSD kernel code for example is something very simple and something that can, if written easily.
That said with this impressive title

what we can do with rust is beyond what we can imagine​

there is in deed something I couldn't imagine:

Rust cannot cope with the FreeBSD kernel > 11.0 unless COMPAT_FREEBSD11 is set. Well GENERIC has set it for downward compatibility reasons.

But as the friends of lean and hardened custom kernel building know this may include risks one want to avoid by unsetting/removing such kernel options.

COMPAT_FREEBSD11 only works thanks to the following:
  1. Apr 7, 2017 How to deal with breaking changes on platform ? [BSDs related]
  2. Sep 17, 2021 Drop support for FreeBSD 10 from std
This is because the Rust ecosystem still depends on some FreeBSD 11 syscalls after the ino64 changes.

The timespan for having this not fixed is impressive given the mouthful "something that can, if written easily".
 
Never used Rust, but no amount of tech merits (even if they really were "beyond imagination", which I doubt) will convince me to use it, because of displays like this:
View: https://twitter.com/rustlang/status/1267519582505512960

Rust Language
@rustlang
Rust believes that tech is and always will be political- take some time today to invest in your community.

I'm from Eastern Europe and sick of propaganda, any kind of propaganda, no matter which side(s) is coming from.

( Don't have or use twitter myself, only found out accidentally about that tweet from https://www.eevblog.com/forum/programming/rust-is-political/ )
 
You're confusing propaganda with political activism. Propaganda by definition uses manipulative techniques, while here, we have a clear statement not trying to hide anything.

Furthermore, refusing to use a technical product because its creators clearly express their opinions is, at least, political activism.
 
There are far more interesting aspects to the language than California-style social activism. On a side note, my favorite over-abused phrase is "x is a social construct". You know, Cargo is a social construct.
 
I don't think giving a statement against police brutality can be directly linked to any talk about "social constructs". I do think almost any individual is political, at least to some extent. Many software projects choose not being political though, and there are good reasons: you avoid the inevitable "flames". I don't know whether anyone thinks, police brutality would be fine ... I suppose not (?) and still people seem to be offended by a project taking a position. This is just unnecessary. IMHO, refusing the project for that is just as unnecessary. Why not just relax....
 
Still an offtopic declaration for a software organization, though you made me lookup the dictionary:

Propaganda
information, ideas, opinions, or images, often only giving one part of an argument, that are broadcast, published, or in some other way spread with the intention of influencing people's opinions
source https://dictionary.cambridge.org/dictionary/english/propaganda

Seems to me like that tweet fits each word from the definition of propaganda.

Whatever it would be called, I'm loathed of everybody spamming whatever cause or ideology they might promote all over other people's life. I don't mind if they go make their own party, or own guerilla, or own organization for their political activism.

Hijacking other organizations or activities to use them for political activism is shitty, and also a dangerous practice. I don't want to see that becoming the norm, so I would avoid Rust at all costs, and will recommend others to stay away from it unless they want to be brainwashed into whatever ideological conformance they might have been practicing there.

I know their behavior is wrong because I've seen this kind of activism done before (during Ceusescu's regime here, in Ro), with political activists taking over the other people's work, or taking over apolitical organizations. It ended very bad here, and in the last couple of decades similar ideological takeovers started to happen again, this time in the western world.

It's the same Animal Farm story happening all over again.
Won't argue any further about this.
 
I don't think giving a statement against police brutality can be directly linked to any talk about "social constructs".
The brutality statement is in a different tweet. "x is political" is exactly like "x is a social construct" or "black lives matter". It's not there for the content (we already know that to be true, there is nothing new or profound), it's a slogan a particular group of people use to identify themselves.
 
Back
Top