Ferrocene 25.11.0 now available

29 points by lonami

freddyb

I was wondering what these certification stands for and what this enables. I did some (very cursory) research and am posting here to save you the time:

Automotive safety (breaks, steering, ...)
Aerospace (autopilot, navigation, ...)
Railway (signaling, driverless sytems, ...)
Medical (radiation therapy equipment, surgical robotic assistant, insulin pumps, )
Industrial machines (e.g., turbine controls for power plants)

qznc
Speaking for automotive there is two big things here if one makes safety-critical things:
1. You must do requirements engineering. Since the Rust project does not do this, Ferrous System does it "on top".
2. There must be errata handling. There must be processes how suppliers inform their customers about dangerous issues. Many are used to CVEs and security issues, generalize this to "any bug". Ferrous System acts as supplier of Rust here.
JulianWgs

For anyone interested in what code written for ASIL D is responsible for:

In particular, ASIL D represents likely potential for severely life-threatening or fatal injury in the event of a malfunction and requires the highest level of assurance that the dependent safety goals are sufficient and have been achieved.

https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level

ancienthero

At a high level, what do these types of certifications mean? I guess it's important for safety critical applications to know that a compiler and it's stdlib do what they say on the tin, but strictly speaking it doesn't say anything about the end software created with them, right?

steveklabnik

You certify a final product.

As part of certifying the product, you have to demonstrate that you're doing certain things with regards to each component in that product.

Some companies sell qualified versions of components, which basically means "we have done the paperwork to ensure that this component follows the standard." What you're then purchasing from that company is said paperwork. This gives you the ability to, when you get to the component in question during the certification process, to say "we're doing the right thing with regards to this component because we have the paperwork to prove it via this purchase."

So yes, it does not say anything about the end software created with them. It does make it economically feasible to produce end software in the space, though.
sknebel

The end software/the overall device is going to be certified too, it "just" is a lot easier to argue that your software behaves correctly and as expected when you can point to evidence that your compiler functions properly. Depending on the type and level of certification, you are allowed to rely on pre-existing certification of components to varying degrees.