Argorak

I mean, all customers got a mid-long email, this does not sound like anyone buries anything.

Unless something has drastically changed, PyCon covers itself and earns the PSF quite some money on top. Here are numbers from 2020:

https://thefortunate.blog/diversification-is-the-future-for-...

> Out of USD4.5MM of revenue for the PSF in 2019, around 63% of it came from PyCon. USD1.9MM was the costs of having PyCon, which means that for every dollar spent on PyCon, the PSF gets back 1.50 dollars.

https://pyfound.blogspot.com/2020/03/psfs-projected-2020-fin...

Obviously, the revenue has sharply dropped for a time because of COVID, but I'd be surprised if PyCon is run at a loss nowadays.

So you can assume none of your sponsorship money goes to running PyCon.

It is and there's the variant where you go bottoms first which is called... "Arschbombe" - "Ass-Bomb".

There's an ongoing discussion about potential adoption into upstream, though.

The thing here is: it would be harmful if we, Ferrous Systems, claimed or even be confused with a more general Rust spec. That's a) the privilege of the Rust project and b) problematic if consumers were to understand it that way.

Yes, and this does indeed happen. Turns out publishing such a thing makes people get in touch.

He, thanks! Weird how that happened though, as the post _was_ edited by an English speaking person living in Germany :).

We're being asked about these regularly, but e.g. bluetooth certification is still too prohibitive to just do without a customer.

However, I'm also frustrated with "everything is customer funded", so we're looking at ways to make this things happen.

Sorry to be vague.

That matches our experience. They were super pragmatic. Also, their feedback was tough, but always technically grounded and from the perspective of "is the user always well informed?".

Yes, we built bindings for LynxOS 178 a while ago and demonstrated Rust on QNX at embedded world.

https://www.lynx.com/press-releases/rust-compiler-support https://ferrous-systems.com/blog/how-we-built-our-embedded-w...

Porting Rust to RTOSes is reasonably easy.

It's certainly an unusual pricing style, but people grok it and appreciate it. Also, note that this is for the "quality managed" version - additional support and documents that I sign off for safety (so enter a liability) are more expensive.

But on the other side, there's so many that would buy if it were more accessible.

(disclaimer: also a co-founder of Ferrous Systems)

The ISO 26262 is certainly an effective standard. The boxes to tick are of the kind "do you have your requirements written down?" ("will someone later know what this thing does?").

So, we do have to tick boxes, but we're free to pick on how to tick boxes :). What TÜV now certified is that our box-ticking process is fine.

I have absolutely no problem with framing this as box-ticking in some way, but that box-ticking has _meaning_. However, on an existing tool, that means you write the spec (spec.ferrocene.dev) and check if everything has a test implemented. Yep, that's an amount of pretty dumb and repetitive work. And pretty often, on widely-used software, for the happy path, you'll find that it's rather bug-free. So, yes, you tick the box, but you now know that this is in order.

In other cases and on less popular platforms, we frequently find issues like e.g. changes in code size between versions (which could hint to a bug). And it's not just super-niche targets, the last version had a size regression on certain arm targets.

Details on some of the fixes over the last years can be found here: https://ferrous-systems.com/blog/how-ferrocene-improves-rust.... We find a lot of things in corners and better ways to improve the Rust compiler.

As we're a downstream to Rust, we're actually incentivised to push changes upstream with preference, so yes, we contribute to the general quality of the Rust compiler (also of older versions) and with that to bug-free-ness of the resulting software.

So, we're over here, ticking boxes, informing parties when one box doesn't tick.

Yep, it's only the target files for lynxos178.

We got hit by this: https://www.cloudflarestatus.com/incidents/t53r6tfsg1sj

Cloudflare served private preview URLs through the deployed website.

Honestly, doing ops for 10 years, i didn't have this in my cards ;).

Footer: © Amazon Web Services EMEA SARL (Niederlassung Deutschland)

This is probably the AWS lead initiative to place their preferred people into a council they see being formed anyways.

This is a German works council, which is the most common outcome of a unionization effort: https://en.wikipedia.org/wiki/Works_council#Germany

Its creation can be forced by a vote of the employees and the council has a legal special status. This probably comes as a reaction to multiple distribution centers around Germany doing exactly that and forcing the creation of local work councils with the help of unions.

I've heard someone once say "if Rust is a criticism of C++, it comes from a position of respect" and that was definitely true in the early days of the programming language.

Interestingly though, I take the stance that Rust is much closer to C than C++.

Sonic Pi is essentially a frontend to Supercollider: https://github.com/sonic-pi-net/sonic-pi/blob/dev/SYNTH_DESI...

Feel free to reach out, it's a topic of interest to us. A good place to discuss is for example the AeroRust Discord or just send me an email. https://github.com/AeroRust/Welcome

Thanks :).

First question: yes. It was hard to talk about the current state of Ferrocene with all the things ongoing last year. Now that I have more bandwidth and we found a development beat, you can also expect more regular updates.

Second question: that was the discussion about higher assurances in the compiler in general. The group did not form, but that's on the project side, where I'm not part of anymore. We're very ready to participate there though.

DO-178C has writing and requirements around dynamic memory management. (DO-332 / ED-217, OO.D.1.6)

Rust also can also model other things through ownership, like passing a device handle safely between components, to avoid concurrent use.

Rust makes quite a few things more rigorous (e.g. pairing allocations with deallocations and reference validity). It basically fulfills the job of a static analyzer baked into the language.

It's also a vastly more analyzable language (in that its syntax is reasonably unambiguous and there's no dynamic runtime in play) and it can be integrated well.

Toolchain quality (error reporting, built in testing, awareness of primitives like "libraries", etc.) is also a huge strong point.

We're reasonably confident that we can use safe Rust as is, with strong guidance on how to do unsafe Rust.

For a tangible investigation of that space, PolySync has a project that has a look at MISRA rules from a Rust perspective. https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul...

Ada is a good example here: the language has not evolved something like MISRA-C (it has evolved SPARK for formal verification, but I see that differently).

There's rubble.

https://github.com/jonas-schievink/rubble

We've been approached by multiple parties to finish it and we are up to it, but the final effort, particularly certification is currently prohibitive. Serious inquiries taken, though - we're also happy to play "consortium" in that this does not have to be financed by any single party.

Let's first get rustc qualified, but speaking on a high level, I believe Ada/Rust FFI has potential to make `unsafe`... safer. If someone wants to play around with this in the open, please don't hesitate to get in touch.

I very much agree. Rust is often seen as C/C++-inspired, but I know a lot of the early team looked at Ada for inspiration. We have also seen in many evaluations of "new stacks" that we were invited in that Ada was evaluated along with Rust. The conclusion was often similar: both languages have matching ambitions, in different forms. Also, there's a ton of places where Ada is just "there" already, e.g. by having something like SPARK available and in production use for many years.

I expressed some of those thoughts in the corresponding post on the Ferrous Systems blog: https://ferrous-systems.com/blog/ferrous-systems-adacore-joi...

I can share from Ferrous side that the partnership started "clicking" when we found our common interest in product quality and user service.

Thanks for taking a moment to give that feedback!

What people generally mistake is that compilers are not certified - they are qualified tools. In this case, the regulators check if the vendor of the compiler uphold certain standards and practices - once. After that, you - the vendor - are allowed to update yourself.

https://ferrous-systems.com/ferrocene/ btw. is our effort to ship rustc with proper support required by most players in the industry.