[HN Gopher] Ferrocene - Rust for Critical Systems
___________________________________________________________________
Ferrocene - Rust for Critical Systems
Author : RebootStr
Score : 69 points
Date : 2023-10-08 17:53 UTC (5 hours ago)
(HTM) web link (ferrous-systems.com)
(TXT) w3m dump (ferrous-systems.com)
| kats wrote:
| > Ferrocene will be available for purchase by individuals and
| companies later this year at EUR25 per month per seat (or EUR240
| per seat if paying annually). Purchasing Ferrocene will grant you
| access to the pre-built binaries and packages of our qualified
| compilers, and the rendered qualification documents for all
| versions of Ferrocene.
|
| That's very low pricing. They won't be able to afford to support
| development if they price that low. It actually decreases
| confidence that their company is legit to see prices that are
| that low.
| konstantinua00 wrote:
| On the other hand, I heard "our current toolchain would cost
| 10x less" at least from one person in one firm in the industry
| AlotOfReading wrote:
| On the contrary, it puts it within small team budgets, so you
| don't need to go through the enterprise purchasing pipeline.
| kats wrote:
| Well, customers need support. Having a lot of small customers
| is harder and more expensive than having 1 big customer. They
| should sell to e.g. a large automotive or industrial
| automation company, and then not worry about the small
| customers till later.
| hgomersall wrote:
| It's the same as the normal rust compiler. The support
| demands are pretty much identical to open source rust.
| AlotOfReading wrote:
| I work for an automotive company you've probably heard of.
| The per-seat pricing being within budgets is exactly why
| we're considering it as soon as the certification stuff is
| available.
|
| Yes, there is nominally an enterprise sales pathway, but
| ferrocene wouldn't succeed there. That has a lot of
| difficult prerequisites and specific timelines that involve
| convincing manager's manager's (managers) that X is worth
| the cost and isn't going to have weird licensing terms e.g.
| preventing us from compiling open source code (a real
| limitation I've seen). The quickest way through that
| pipeline is if we already have a bunch of internal usage on
| prior projects to point to, or well-known public usage.
| [deleted]
| [deleted]
| kats wrote:
| e.g. lets say that the big initial cost of certifying the first
| version of the toolchain is $2 million. It will be more than
| that, but (probably?) less than $10 million. And this doesn't
| include any salaries or costs beyond the time to get the big
| up-front work done.
|
| Let's say they were to sell just that one compiler version for
| 5-10 years. Then they need 800 licenses (which for developers
| of certified products, is actually quite a few) to make back
| the 2 million over 10 years.
|
| Suggestion: maybe a better possibility would be: find one
| customer who will pay at least a few million dollars. Then list
| the pricing as 'contact us' while they find a couple other
| large customers. Don't publish the low price/seat or the bigger
| customers may ask for lower prices.
| bfrog wrote:
| This seems like a possible beacon of safety critical rust,
| especially given that it's SIL 4 and ASIL D (impressive!), the
| price structure is very reasonable, and its open source!
|
| It's really quite amazing what the team there has done and I'm
| looking forward to this perhaps bringing some new eyes to where
| and how Rust might be used.
| tialaramex wrote:
| If you need certification, then this is what you need and
| hopefully you were already aware of Ferrous Systems before. If
| you don't need certification (which will be most people) then
| this doesn't really do anything except reassure you that the
| software feels like it could be safety qualified because
| essentially identical software is safety qualified.
|
| I actually hope there's inspiration for the other side of the
| fence. ISO 26262 ASIL D ought to be a higher bar than it is,
| it's not at all clear to me that "Oh yeah, off the shelf
| general purpose languages can do ASIL D" is the right setting
| of expectations, but that's where we are today. I'd be more
| comfortable if for these roles (this is software which if it
| malfunctions might literally just kill a whole bunch of people)
| we were demanding a bit more, maybe a lot more, than is
| currently in that ISO document.
| galangalalgol wrote:
| Looking at their fork, I don't think it could do ASIL D until
| they upstreamed some stuff. And it isn't like rust is a
| generic language, it was designed to make reasoning about
| correctness easier, at the cost of anything else but
| performance, and even that if necessary.
|
| Are there specific things you think should be in these
| standards? For a compiler I mean, there are things you'd
| require of deployed asil d code you don't really care about
| for a compiler. Like, if the compuler panics, that is
| probably fine. If my ABS controller panics, it isn't.
| tialaramex wrote:
| It's a _General Purpose_ language, not a "generic"
| language that's a particular kind of thing, depending on
| how much you've been exposed to you may never have seen any
| programming languages which aren't general purpose because,
| tragically, we seem as an industry to have decided we all
| want a single tool - we want to buy a chainsaw and then use
| that to cut everything, toenails, steak, trees, the tags in
| new clothes, everything gets the chainsaw treatment because
| apparently we don't like learning new things.
|
| Special Purpose languages are very narrow, they solve one
| problem and they solve it really well, but if you have a
| different problem then too bad. I think we should use these
| much, much more often, and we should have many more of
| them, but we don't and for the foreseeable future we won't.
|
| Because a Special Purpose language only solves a narrow
| problem it often gets to sidestep lots of horrible Computer
| Science problems which arise for general purpose languages.
| To revisit our chainsaw analogy, while using a chainsaw to
| cut the tags out of your new shirt has lots of
| opportunities for truly life altering (or ending)
| accidents, if we use instead a tool that's purpose made the
| potential accidents are trivial. Oh no, I slipped while
| using the tag removal tool and... didn't remove the tag.
| Better try again.
| steveklabnik wrote:
| Just FYI three days ago someone from Ferrous said the list
| of not upstreamed changes is in the tens of lines:
| https://news.ycombinator.com/item?id=37771664
| worik wrote:
| What does buying it get you?
| steveklabnik wrote:
| In my understanding, LTS support and the certification
| documentation.
| fbdab103 wrote:
| Not just the toolchain, I want to see a vetted library
| collection. Make it annual releases, "Rusty MetaLib 2023" which
| packages a majority of the standard players (regex, clap,
| num_cpus, SQLite, serde, time, etc).
|
| I have minimal Rust experience, but I really enjoy nearly
| everything about it. Except for the large dependency trees I am
| likely to pull in when building something more complicated than
| Hello World. Impossible to feel safe that all of that code has
| not been compromised.
| galangalalgol wrote:
| The crates are very granular. They are almost used like modules
| in other languages. And procedural macros currently require a
| separate crate. My point is that you probably have fewer
| authors than you think in those few hundred dependencies.
|
| Second, the situation isn't appreciably better if you count by
| authors for c/c++. Running nm or whatever on a decent sized
| modern c++ thing is enlightening. Much of that is plastered
| over by the lack of a coherent package manager for those
| languages, so you end up using thebpackage manager for whatever
| distro your container is and you think "well thats all just
| RHEL stuff, I'm sure they vetted it"... but grpc by itself has
| a dozen or so dependencies not counting the ones it expects
| from the os. And that is a long list too. So we are in this
| situation with any language. Rust just makes it easy to see,
| which is good.
|
| Cargo deny can block your pipeline on cves (or a license you
| don't want) popping up in your dependency tree. If you pin to a
| hash, and stick with it until you need a new feature or a cve
| appears, then that is about as safe as you can be right now.
| Austral has granular permissions for packages which would be
| even better, but it isn't here yet.
|
| Lastly, the list of crates that get used to build rust itself
| is quite long, and I would presume some paths through those
| libraries got very closely inspected for the certification.
| Crates like tokio and clap and yesh num-cpus.
| timmclean wrote:
| For supply chain security, you might be interested in cargo-
| vet[0], a tool for coordinating and requiring manual reviews of
| open source dependencies. Both Mozilla and Google[1] have
| started publishing their audits.toml files, which are machine-
| readable files describing what source code reviews they have
| performed.
|
| [0] https://github.com/mozilla/cargo-vet
|
| [1] https://opensource.googleblog.com/2023/05/open-sourcing-
| our-...
| dang wrote:
| Related:
|
| _Open Sourcing Ferrocene_ -
| https://news.ycombinator.com/item?id=37767525 - Oct 2023 (19
| comments)
|
| _Ferrocene update_ -
| https://news.ycombinator.com/item?id=37711274 - Sept 2023 (14
| comments)
|
| _How Ferrocene Improves Rust_ -
| https://news.ycombinator.com/item?id=37465484 - Sept 2023 (1
| comment)
|
| _A Decade of Rust, and Announcing Ferrocene_ -
| https://news.ycombinator.com/item?id=36785318 - July 2023 (47
| comments)
|
| _Ferrocene: Rust toolchain to safety-critical environments_ -
| https://news.ycombinator.com/item?id=32237780 - July 2022 (32
| comments)
|
| _The Ferrocene Language Specification_ -
| https://news.ycombinator.com/item?id=31582469 - June 2022 (5
| comments)
|
| _Ferrocene: Road to Rust in mission and safety-critical software
| development_ - https://news.ycombinator.com/item?id=27641160 -
| June 2021 (2 comments)
|
| _Ferrocene Part 3: The Road_ -
| https://news.ycombinator.com/item?id=26260519 - Feb 2021 (1
| comment)
| d-z-m wrote:
| related: https://highassurance.rs/
| Alifatisk wrote:
| Mozilla, the creator of rust, is their clienr? Impressive
| Lev1a wrote:
| AFAIK not Mozilla but one of their employees created Rust and
| later on Mozilla sponsored development and used the language
| for projects.
| [deleted]
| robocat wrote:
| Software developer Graydon Hoare created Rust as a personal
| project while working at Mozilla Research in 2006. Mozilla
| officially sponsored the project in 2009.
___________________________________________________________________
(page generated 2023-10-08 23:02 UTC)