[HN Gopher] Officially Qualified - Ferrocene
___________________________________________________________________
Officially Qualified - Ferrocene
Author : jamincan
Score : 267 points
Date : 2023-11-08 10:49 UTC (12 hours ago)
(HTM) web link (ferrous-systems.com)
(TXT) w3m dump (ferrous-systems.com)
| weinzierl wrote:
| This is big news in my opinion.
|
| _" We've qualified Ferrocene for use in systems up to ASIL D"_
|
| Where D is the highest existing level used for systems that can
| potentially cause fatal injuries.
|
| From my understanding that means that now Rust can be used for
| the development of security critical software in automotive.
|
| I used to work in automotive and where I worked software
| development was dominated by ancient and archaic compilers and
| toolchains. Even if it wasn't for the advantages that Rust brings
| to the table the possibility to use a modern toolchain would be
| revolutionary. At the same time this is the biggest risk for
| adoption because these legacy systems are deeply ingrained and
| intertwined with existing processes that often span multiple
| tiers of suppliers and will be hard to change.
| pjmlp wrote:
| While it is great that Rust is now also an option, some of
| those places still stuck in C89 and C++98, are hardly to going
| upgrade to anything else.
|
| Some times not even the tooling is an excuse, as most chip
| vendors do at least support C11 and C++14 in most cases.
| Xylakant wrote:
| Disclaimer: I'm one of the founders of Ferrous Systems
|
| To some extend I agree, but from our conversations with OEMs,
| Tier 1 and Tier 2 suppliers we do see a significant interest
| in moving to rust, much more than moving to a new C/C++
| version.
|
| The reasoning is that moving to a new C/C++ version is an
| incremental change, but moving to rust signifies a jump to a
| different tech level (let's set aside whether that's true on
| a technical level or not, I'm talking about perception). One
| of the signifiers is that we were able to qualify the rust
| language as it exists, with no such restrictions such as
| Misra C etc. So no "reduce use of pointers" etc.
|
| The other things that's helping is regulatory pressure. The
| CISA, DARPA etc are all advocating strongly in favor of
| moving to memory safe languages, and for the chunk of the
| market that used C/C++ before, rust is a pretty good offering
| there: It binds to C both ways, that means not only can you
| call C code from rust, but also the other way round - you can
| build a component in rust and integrate it in your existing
| firmware. That's a rare capability.
|
| Chipset and ecosystem support are IMO the biggest hurdles at
| the moment, but with Ferrocene as a qualified compiler, at
| least that one bar is removed. It's still a long way to go
| and a lot of work ahead of us :).
| pjmlp wrote:
| I see human behavior a more problematic issue to overcome
| than the toolchains, hence why I mentioned the toolings
| being more modern than what many are willing to adopt.
|
| Looking forward to regulatory pressure to help improving
| the situation, not only regarding the adoption of modern
| safer languages, but also to "just" adopt modern practices
| and tools while coding in C and C++.
|
| Already changing the mentality from unsafe at any speed, to
| quality matters, would be a big improvement.
|
| A plus from safer languages that aren't copy-paste
| compatible with C, is that C style programming is already
| taken out, so we don't need to spend time creating
| SonarQube rules and forcing them into teams.
|
| Good luck with the Ferrocene effort.
| Xylakant wrote:
| > I see human behavior a more problematic issue to
| overcome than the toolchains, hence why I mentioned the
| toolings being more modern than what many are willing to
| adopt.
|
| I absolutely agree. I agree that this is what's holding
| back adoption of new tooling the most. However, the
| impression that I get from our conversations is that a
| new C/C++ is seen as "more of the old thing" while rust
| is considered a break with the old thing, something new
| with substantial risk, but also substantial upsides. This
| perception helps when it comes to considering an
| adoption.
| cryptonector wrote:
| We need an industry-wide break with the old thing. There
| have been enough problems caused by crappy unmaintainable
| spaghetti code full of UB. Now, a new thing (Rust)
| doesn't mean you'll get better code in every way, but at
| least in some ways.
| zozbot234 wrote:
| > From my understanding that means that now Rust can be used
| for the development of security critical software in
| automotive.
|
| What about other safety critical domains such as aerospace,
| medical, railways, machinery, process control etc? It seems
| like each of these has its own bespoke standards, so Ferrous
| will need to seek certification for these separately?
| twic wrote:
| As the article says:
|
| > Beyond the automotive, Ferrocene can also be used in
| electronic programmable systems in the industrial sector.
| Here the focus is on developing products or applications that
| carry out safety functions. Like the automotive
| certification, we've also gone for the highest level of risk
| reduction and qualified it at SIL4.
|
| Apparently [1] the SIL standard is used in at least the
| process control, nuclear, mechanical, and railway industries.
| Not sure about medical or aerospace.
|
| [1] https://en.wikipedia.org/wiki/Safety_integrity_level#Stan
| dar...
| Xylakant wrote:
| Aerospace would be DO-178, which is on the roadmap, but
| will take some effort (a year or two, give or take).
|
| Medical is closer: While there are dedicated certifications
| for medical, they are relatively close to the IEC 61508
| industrial standards and so IEC certifications are often
| used as a stand-in for the equivalent medical
| certification.
| kejaed wrote:
| Keeping an eye on this in the aero, uh, space. Very
| interesting progress, keep up the good work.
| twoWhlsGud wrote:
| Isn't AdaCore handling the DO-178 side? Or does Ferrocene
| intend to have an offering here, also?
| Xylakant wrote:
| The joint venture with AdaCore is no longer, so yes,
| we're doing this seperately.
| galangalalgol wrote:
| Please beat them to market... Their notion of advertising
| "curated language features" as a positive instead of
| "weird frankencompiler that doesn't match any version,
| work with any 3rd party crates, and has complete vendor-
| lock" will sell well to people that already use them,
| unless they aren't an option.
| sheepshear wrote:
| I didn't think they made any language extensions for
| rust? Thought it was just for Ada.
| thesuperbigfrog wrote:
| Ada does not have any formalized FFI with Rust at this
| time; just C, COBOL, and Fortran:
|
| http://ada-auth.org/standards/22rm/html/RM-B.html
|
| AdaCore has a Rust toolchain:
|
| https://www.adacore.com/gnatpro-rust
| sheepshear wrote:
| I know, thank you, but I'm asking about the "curated"
| language features gp is criticizing. AdaCore does make
| Ada language extensions (who else would push the language
| forward these days?), but I didn't think they had any for
| rust, which is why I'm asking.
| galangalalgol wrote:
| > GNAT Pro for Rust offers yearly updates that
| incorporate selected, recent enhancements from the
| upstream development. We make sure the result is a
| stable, tested Rust toolchain that's ready to be used and
| supported for years to come.
|
| https://www.adacore.com/gnatpro-rust
|
| Edit: not so worried about the extensions, more worried
| they will keep re-releasing 1.68 forever with features
| added only as people clamor for them. And security fixes
| wedged into old code. That is in effect forking the
| language.
| sheepshear wrote:
| The direct competition between Ferrocene and AdaCore
| should take care of that.
|
| In any case, the compiler wouldn't be certified if they
| didn't vet the new features. These companies can't
| control what gets added to the language, and it might
| take longer than a year to vet future changes.
|
| Their statement is an upfront, no-bull fyi about how
| reality works. I highly doubt it's a statement of intent
| to stagnate. It would kind of defeat the purpose of
| switching away from a stagnated language and ecosystem.
| galangalalgol wrote:
| I can imagine no use case where ripping out features from
| upstream reduces risk vs adding it. I agree it makes no
| sense to stagnate, but I am familiar with the certified
| compiler space, and what I have described is exactly what
| I have witnessed. Compilers that are based on ancient
| versions of open source compilers, and have code
| incorporated from various point releases since then to
| minimize the amount of recertification necessary.
| thesuperbigfrog wrote:
| >> That is in effect forking the language.
|
| It feels like the effectiveness and success of Rust could
| make that happen.
|
| Different industries have different needs and will want
| the language to meet their needs.
|
| Rust needs more funding, labor, and organization to
| create an official language standard to prevent it from
| fragmenting.
| galangalalgol wrote:
| Ferrous created a language specification.
| https://github.com/ferrocene/specification
|
| They do say any differences between it and upstream
| behavior or documentation is a defect in the spec, not
| upstream. So it isn't authoritative. Unless we all decide
| it is.
| thesuperbigfrog wrote:
| They have explicitly stated that a Rust language
| specification is a non-goal for Ferrocene:
|
| https://news.ycombinator.com/threads?id=thesuperbigfrog&n
| ext...
| Argorak wrote:
| 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.
| zozbot234 wrote:
| Doesn't Rust have a Reference manual already? A "spec"
| just wouldn't be very meaningful given the lack of
| independent implementations. But to the extent that the
| reference manual doesn't suffice for documenting the
| language, that's a defect which could and should be
| fixed.
| thesuperbigfrog wrote:
| >> AdaCore does make Ada language extensions (who else
| would push the language forward these days?), but I
| didn't think they had any for rust, which is why I'm
| asking.
|
| Correct, AdaCore / GNAT has extensions that are not part
| of the Ada standard:
|
| https://docs.adacore.com/gnat_rm-
| docs/html/gnat_rm/gnat_rm/g...
|
| I don't have a close relationship with AdaCore and do not
| know what they are planning for their Rust toolchain.
|
| That said, I would be surprised if they do not add
| features to ensure Rust plays nicely with their other
| products and give their Rust toolchain competitive
| advantages in the safety critical space. I do not see any
| documentation or details on their website yet, but it
| also looks like their Rust toolchain is not released yet.
| ska wrote:
| The medical certifications are mostly about design & risk
| control, there isn't really (currently) the same set of
| toolchain certs you see in e.g. aerospace. Some places do
| use them as a shorthand for "our documentation & testing
| here is minimal, because we use X certified tools and/or
| standards" but it isn't required for CFR21 or 13485.
| tialaramex wrote:
| > From my understanding that means that now Rust can be used
| for the development of security critical software in
| automotive.
|
| It has always been _possible_ to do whatever you wanted in this
| respect, Ferrocene means that you don 't have to go to more
| trouble than a competitor who does their software development
| in a similarly qualified C++ software suite.
|
| Rather than pay some number of people to explain why it's OK
| that you didn't do the boring normal thing, you can pay
| Ferrocene for their paperwork which says actually Rust is just
| one of the boring normal things.
|
| Is "Boring normal thing" good enough? Well, on its own I'd
| argue it's not even close, but pragmatism rules the day, people
| writing firmware which is in pretty old cars were knocking it
| together in C with no rules, and most people didn't die, so,
| that's our baseline, that was apparently OK, logically a bit of
| that won't be a disaster... right?
|
| It reminds me of GRAS rules. On the one hand, there's no
| particular reason to just assume parsnips are OK food while
| this random thing my chemists just invented is not - after all
| parsnips may be "natural" but so are all nightshades and some
| of them are straight up poison (and indeed the rest of
| Apiaceae, the family parsnips are in, are sometimes poisonous)
| - however on the other hand a lot of people have eaten parsnips
| already and they _seemed_ fine, so, maybe that 's enough reason
| to require tests for my chemical but not parsnips ? Or at
| least, lets not _require_ the tests before continuing to eat
| parsnips.
| weinzierl wrote:
| _" It has always been possible to do whatever you wanted
| [..]"_
|
| That is not quite what I meant. You can always do what you
| want if you are prepared to accept the consequences.
|
| German law requires the manufacturer of a technical product
| to take all measures objectively necessary and reasonable in
| order to avoid danger and harm. In automotive safety critical
| systems ISO26262 is a legally well established, necessary
| (but not necessarily sufficient) prerequisite for that.
|
| Car manufacturers spend a ton of money on certified compilers
| and toolchains for good reasons. One of them is legal
| compliance.
|
| _" From my understanding that means that now Rust can be
| used for the development of security critical software in
| automotive."_
|
| What I meant here is that I'm not sure if what exists today
| (including Ferrocene's certified toolchain) is enough to make
| Rust happen in safety critical automotive applications. I
| simply do not know enough to make that claim.
| Xylakant wrote:
| > In automotive safety critical systems ISO 26262 is a
| legally well established, necessary (but not necessarily
| sufficient) prerequisite for that.
|
| That is true, but an ISO 26262 qualified toolchain is
| neither sufficient nor required to achieve certification.
| It certainly helps when the auditor looks at your project,
| but you can also opt for other measures. So you could build
| ISO 26262 certified software in rust even before the
| Ferrocene qualification, and you still can build it using
| stock rustc, but it's more work. Few people will do that
| and rather opt for a qualified toolchain.
|
| > What I meant here is that I'm not sure if what exists
| today (including Ferrocene's certified toolchain) is enough
| to make Rust happen in safety critical automotive
| applications.
|
| It's one of the foundational pieces, but others are
| qualified libraries and the entire ecosystem. So the
| adoption will by necessity still take time. We do have a
| few exciting things in the pipeline there, but that's news
| for another day (it's christmas soon, not all presents at
| once)
| weinzierl wrote:
| Very true. I'm coming from the supplier side and in the
| world I know the required ASIL level is a box we have to
| tick, no realistic way around it. That includes using a
| certified compiler. Probably that is not universally true
| but in my bubble for all intents and purposes a certified
| compiler was a hard requirement. This is in no way a
| contradiction to what you wrote but underlines why I
| think a Rust compiler that is not in the way for me
| ticking the ASIL D box is a big thing.
| DoingIsLearning wrote:
| > Rust can be used for the development of security critical
| software in automotive.
|
| Perhaps you are native of a latin language?
|
| In the context of ISO26262, ASIL levels relate to the
| criticality of _safety_ not security.
|
| My house's security will determine how easily someone can break
| in.
|
| My house's safety will determine how well it will survive a
| hurricane.
| weinzierl wrote:
| Oh yes, you are right, in my mother tongue safety and
| security are the same word. It is still embarrassing, I
| should have been more careful.
| chromatin wrote:
| Wait -- I find this fascinating.
|
| They are also kind-of the same word(s) in German
| (Sicherheit / Sicherung).
|
| Do native German speakers draw much distinction between
| Sicherheit and Sicherung, and to the same degree that we do
| in English?
|
| If no, I am curious how the differentiation in concepts
| developed in English developed and whether it is also
| present in other Germanic languages.
| Megranium wrote:
| Hmm in German you could also say "Betriebssicherheit"
| (safety) vs. "Angriffssicherheit" (security), or at least
| that always was the translation that made most sense to
| me personally.
|
| I'd say native speakers of German distinguish it but it
| depends on the context ... talking about computers, it's
| typically more about security, while when talking about
| construction sites, it's typically more about safety.
| tecleandor wrote:
| For somebody not familiar with compilers, rust or ASIL...
|
| What's the difference between the regular rust compiler and
| Ferrocene that makes it adequate for critical systems?
| ijustlovemath wrote:
| In a word: documentation and testing. They're not making major
| modifications to upstream, but they are crossing the Ts and
| dotting the Is to satisfy the that their compiler meets all the
| safety requirements set forth in those standards.
|
| As far as why use their compiler vs upstream? It's similar to
| why you might use a managed database vs deploying your own in a
| $5 droplet; in a big corporate environment, you have no trouble
| paying for things that would be hard to do yourself, and
| satisfying regulators is one of those things.
|
| All at a very reasonable price point, too!
| tecleandor wrote:
| I mean, I was thinking more like:
|
| What's the merits that allow the certification? Is it
| technical? Is it bureaucracy and "just" certifications?
|
| I've been on the healthcare business so I've seen how that
| works when doing FDA or CE certifications.
| Xylakant wrote:
| Disclaimer: I'm one of the founders of Ferrous Systems.
|
| Ferrocene as a compiler is not inherently more suitable for
| safety critical applications than stock rustc as
| distributed by the rust project. It is for all intents and
| purposes the rust projects compiler, with all the
| certification paperwork - that's quite a stack of paper if
| you include all of it, but it doesn't change any of the
| functionality.
|
| However, on a support/organizational level, there are quite
| a few differences. We run our own CI for all of our
| supported targets which allows us to provide different QA
| levels than the rust project does or even could support.
|
| We do provide higher levels of assurance on some targets
| compared to upstream. For example, the aarch64-unknown-none
| target is treated as "tier 2" by the Rust project, meaning
| they don't run any tests for it. Instead, Ferrocene treats
| it as fully supported, and we ensure all tests pass on it
| when we merge any change (contributing back fixes when
| something breaks).
|
| We can also provide support for targets that are not in the
| rust projects tree, or even require legal paperwork for
| access to test hardware etc., to the point that we can
| provide binary only targets that cannot be made available
| via the rust project.
|
| On a support level, we also provide support for existing
| rust version, to the point of long term support for
| certified versions (2 years by default, more or less
| infinite with a separate support contract).
|
| There's also minor things that are interesting to
| organizations: Notification of known issues, signed
| installers, ...
|
| All of these things do not change the compilers behavior,
| but can be quite essential for organizations with long
| term, safety critical projects.
| tecleandor wrote:
| Aaaaaah OK. So it's a bit more like a certified
| distribution. Sounds similar to how we handled FDA/CE
| certified versions of Open Source software.
|
| Thanks for the clarification, it's very useful!
| weinzierl wrote:
| Is there a list with supported targets? Do you focus on
| ARM or are there other targets common in automotive, for
| example Power Architecture like the NXP MPC series?
| Xylakant wrote:
| Depends on what you mean with ,,supported" - the
| qualification is at the moment for ARMv8-A bare metal
| (aarch64), see https://public-
| docs.ferrocene.dev/main/qualification/report/..., mostly
| because that's what our initial customer intends to use.
|
| We have other targets on the roadmap and can
| implement/qualify targets on request, so if you're
| interested in a specific target, we'd be happy to talk.
| avgcorrection wrote:
| > What's the merits that allow the certification? Is it
| technical? Is it bureaucracy and "just" certifications?
|
| What's the _technical_ difference between bureaucracy and
| technical merit in this context? Two compilers with equal
| source: (1) is rubber-stamped (audited or whatever by
| humans) while (2) is not.
|
| This is based on rustc(1) so _a priori_ I wouldn't expect
| much technical difference (other than perhaps the Ferrocene
| fork lagging behind a bit).
| Xylakant wrote:
| You are correct, the technical differences are negligible
| for most intents and purposes.
|
| However, the certification covers not only the source
| that was used to build, but rather the entire process to
| produce the binary for the source, that is our (Ferrous
| Systems) organization, our processes, the review process
| to ensure that requirements match the tests, the CI, the
| quality management, how we handle new issues (for example
| reporting to customers) ... So even if you'd build the
| Ferrocene compiler from the available Ferrocene source,
| this would not give you a qualified compiler - because
| it's not been built by our standards.
|
| So to a large extend, the qualification does not produce
| better software, it ,,just" documents that a certain
| quality baseline is fulfilled. But, as part of the
| qualification process we test the qualified targets to a
| higher standard than the rust project itself - the
| aarch64-unknown-none target is a tier 2 target for the
| rust project, it's built as part of the compiler release
| but not tested. It's our qualification target so for us
| it's tier 1. And indeed, we did discover issues as part
| of the certification effort, so ticking the boxes to
| fulfill that baseline did indeed improve the rust
| compiler. We wrote a little about the things that came
| out of the certification process in an earlier blog post:
| https://ferrous-systems.com/blog/how-ferrocene-improves-
| rust...
| Vespasian wrote:
| Certification is super important in many industries like
| automotive.
|
| Your customers will do audits and send people to cover their
| own asses and stay in legal complience. Now a venturing
| software developer (or teamlead) can go to their bosses and ask
| them to use this new fangled rust technology for a small test
| project.
|
| It can be sold as a chance to innovate without compromising on
| customer requirements/safety. After all it's offically
| certified to some standard and the responsible manager can
| check that off their list.
| HankB99 wrote:
| I was really hoping that certification involved some kind of
| testing to insure that the compiler always produces correct
| code, though I'm not sure that's even possible. "Always"
| covers a _lot_ of ground.
|
| It sounds like it's more a "cover your ass" kind of thing. Is
| there any part of the certification that involves behavior of
| the tool?
| Xylakant wrote:
| Disclaimer: I'm one of the founders of Ferrous Systems
|
| > I was really hoping that certification involved some kind
| of testing to insure that the compiler always produces
| correct code, though I'm not sure that's even possible.
|
| This is not what certification does or even aims to
| achieve. To boil it down in very few (grossly simplifying)
| words, certification provides a process framework that
| ensures that defects found are handled and adressed. No
| compiler is perfect and none will ever be, but the goal is
| to document the behavior of the compiler (which we did by
| boiling down all of the RFCs into the ferrocene language
| spec https://spec.ferrocene.dev/index.html), ensure that
| all of these requirements have associated tests and
| document that association and then document where the
| compiler misbehaves, as well as ways to detect and avoid
| that misbehavior.
|
| If misbehavior is found in a future rust version, our task
| is to identify which of the certified version(s) are
| affected and notify our customers on how to handle the
| issue. Handling the issue does not always require a patch
| to fix it, it can also be handled by providing a suitable
| tool to detect it (a lint, binary checker, ...) and
| associated documentation on how to adress it in the
| customers code.
|
| > Is there any part of the certification that involves
| behavior of the tool?
|
| The spec, plus the associated safety manual.
| baq wrote:
| You weren't joking about the height of the stack of paper
| in another comment.
| Xylakant wrote:
| No, not at all.
| HankB99 wrote:
| Thanks for explaining that.
| londons_explore wrote:
| What impact does certification have on the safety of the
| resulting systems?
|
| Is this one of those standards which involve a lot of
| questionnaires and box-ticking, but has negligible effect on the
| bug-free-ness of the resulting software?
| dgacmu wrote:
| The biggest practical impact is probably from having the CI
| tests running on the certified platforms that were not already
| tier one for rust.
| Argorak wrote:
| (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 TUV 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.
| lucasyvas wrote:
| It seems like it would be cool to have a "rustup" variant that
| used this so it was a smooth setup to get a certified tool chain.
|
| That said, I don't code for such environments so I don't know if
| they prefer to piece their tools together or if there are other
| reasons to not bother.
| pietroalbini wrote:
| We're working on that! Expect more news around it in the coming
| months.
| Game_Ender wrote:
| This is very exciting, the interop with C really opens the
| ability to fold this into an existing OS and drivers. Any
| existing examples of operating system integration, for example
| working with SafeRTOS [0].
|
| 0 - https://www.highintegritysystems.com/safertos/
| Argorak wrote:
| 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.
| dwroberts wrote:
| I was expecting it to be locked to quite an old rust, just
| because of how difficult/slow it is to get this kind of
| accreditation, but it's 1.68 which is not bad at all (latest
| stable is 1.73)
| faitswulff wrote:
| Can any of the Ferrocene folks here can talk about what the
| release cadence for officially qualified Rust toolchains might
| be?
| Xylakant wrote:
| A lot of the timeline depends on the partner we're working
| with to achieve qualification. Initial qualification
| definitely takes longer, but we're having discussions on how
| we can cut down on the manual part of the certification. We
| do for example pull in all releases of the compiler,
| including nightly, and build them using our CI and test
| sytems. The versions that pass are made available to our
| customers, so they can follow the release cycle - though
| these are obviously not qualified and nightly comes with the
| usual nightly (lack of) stability guarantees.
|
| I obviously can't make any promises here, but we aim to pick
| two of those rust versions per year and then certify them -
| how long that takes depends on the feedback we get from the
| auditor and on their availability. The exact cadence will
| need a little shakedown - no one has experience in qualifying
| rust compilers continously :)
| the_duke wrote:
| Side question:
|
| Is your pricing in line with the norms in this sector? It
| seems really cheap to me.
| AlotOfReading wrote:
| From past experience, other companies in this space
| typically charge 1-2 orders of magnitude more per seat.
|
| Their products are also usually worse than the free/OSS
| options that don't come with certification paperwork.
| whizzter wrote:
| They're a new entry into the space and with something as
| "groundbreaking" as Rust their idea is probably to push
| for better/cheaper up until there is enough seats that
| they can start charging more once people have invested
| enough to not want(or be able) to change toolchains.
|
| At that point they not only have locked in customers,
| they also have them as references for other customers to
| justify why new customers should pay more (Existing
| customers will probably be the ones paying least for the
| longest).
| hobofan wrote:
| > until there is enough seats that they can start
| charging more once people have invested enough to not
| want(or be able) to change toolchains
|
| I can understand how one could have that impression about
| generic suppliers in the field. However from everything I
| know about the people at Ferrous Systems, I'd be
| incredibly surprised if that's a strategy they are
| pursuing.
| Xylakant wrote:
| Thank you, we appreciate the compliment :)
| Xylakant wrote:
| I'm happy to outline our general reasoning of how we
| arrived at the pricing, though I'll obviously not go into
| specifics.
|
| First of all, our competition is the open source rust
| compiler. Current Ferrocene is a downstream of rust 1.68
| and a drop in replacement, so you can develop your
| project using the open source rust compiler and at the
| point where certification is required switch. You
| obviously won't get support, but the safety manuals and
| all the certification documentation is open source. The
| compiler source is also open source, so you can build
| from our source.
|
| So our offering is essentially the quality management and
| handling of all the minutiae required to use a compiler
| in a corporate environment, including LTS support when
| required, signed installers, management of known issues,
| certifications, etc.
|
| We could ask for prices an order of magnitude higher if
| we kept all the documentation closed, but that would mean
| our customer base is the people that require
| certification now. We'd rather have a reasonable price
| point and charge for the work we save the user - which
| puts a reasonable upper bound on the per seat price.
| Also, that ship has sailed - as I said, all accompanying
| documentation is open, which also keeps us honest.
| Argorak wrote:
| 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.
| bonzini wrote:
| According to (second-hand) experience with auditors with
| respect to open source, they were quite open to considering
| things like CI, good commit messages etc. are useful when
| evaluating the development process, and even considered
| them sufficient (with adequate explanation) towards some of
| the ISO26262 requirements. However, that was for ASIL B
| only.
| Argorak wrote:
| 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?".
| linuxlizard wrote:
| I'm very excited about this. Having a vendor supported toolchain
| means I might be able to bring Rust into where I work. Embedded
| companies are very conservative and risk adverse. Have a
| commercial package with LTS and certifications addresses some of
| the concerns.
| thatxliner wrote:
| "Rust was designed specifically to handle concurrent and parallel
| programming"
| BD103 wrote:
| Congrats! Ferrocene has been building towards this accomplishment
| for a while. I definitely appreciate the amount of hard work that
| went into this. (And as a fellow Rust user, all the improvements
| and changes that get merged upstream.)
| juliangmp wrote:
| I've met some people from ferrous before (during one of their
| rust courses) and I have to say I was quite impressed with their
| work.
|
| They went through the qualification without a fork of the
| compiler. The changes they made are upstream, and all open
| source.
| littlestymaar wrote:
| That's a vert smart move actually: the value their customers
| are paying for is the certification/paperwork, so upstreaming
| doesn't cost them anything and it reduces their costs a lot
| since they don't have yo maintain their fork, which can be an
| extremely costly endeavor in the long run.
| WiSaGaN wrote:
| Any example PR? I am curious about what they look like.
| steveklabnik wrote:
| Here is one I know of: https://github.com/rust-
| lang/rust/pull/90346
|
| I _believe_ this is one as well: https://github.com/rust-
| lang/rust/pull/113535
| Xylakant wrote:
| The second one was for a demo at an ESA symposium about
| rust in space, so it's not directly related to the
| certification.
| Xylakant wrote:
| We wrote a blog post about it which lists some of the things
| we upstreamed https://ferrous-systems.com/blog/how-ferrocene-
| improves-rust...
| Sytten wrote:
| Will you guys provide certified libraries as well? Like an async
| executor, http client, bluetooth, etc? That would be something
| even companies outside the target for certification would
| probably be interested in.
| Argorak wrote:
| 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.
| stefanoco wrote:
| On this topic (certified libraries) I suspect an interesting
| evolution might happen: by observing how you guys at Ferrous
| achieved this milestone while keeping a consistent openness,
| other actors (companies, consultancies and academic
| institutions) start seriously thinking about the possibility
| of contributing with high quality and certified libraries for
| a lot of scenarios. In other words I'd look at this as a
| milestone that opens to new and disrupting ideas
| Argorak wrote:
| Yes, and this does indeed happen. Turns out publishing such
| a thing makes people get in touch.
| 1-KB-OK wrote:
| Huge! Congrats to the team.
| KwanEsq wrote:
| If someone from Ferrous sees this, I'd advise putting the price
| in English punctuation when writing the article in English. It's
| a needless stumbling block having the comma and period in the
| wrong place.
| Argorak wrote:
| He, thanks! Weird how that happened though, as the post _was_
| edited by an English speaking person living in Germany :).
| stefanoco wrote:
| This is a milestone and a landmark achievement. And the reasons
| for this are not limited to the availability of a qualified and
| vendor supported toolchain for the use of Rust in Functional
| Safety concerned embedded designs. The goal has been reached
| while maintaining openness and shared results, which is an
| industry first.
| ruuda wrote:
| Aside from having gone through the certification, what are the
| differences between Ferrocene and upstream rustc?
| steveklabnik wrote:
| "Measured in literally tens of lines"
|
| https://news.ycombinator.com/item?id=37771664
|
| for more: https://ferrous-systems.com/blog/qualifying-rust-
| without-for...
___________________________________________________________________
(page generated 2023-11-08 23:00 UTC)