However, most relevant regulation (IEC61508, ISO26262, DO-178X) requires that systems controlling machines in automotive, rail or aerospace have a possibility of dangerous faults lower than 10^-9 (over the expected lifespan).
Many critical control systems like this are formally verified and/or extremely well-tested and have redundancy in both software and hardware.
I do development and DevOps on it. Sure there are some intense workloads that I probably couldn’t run, but it works just fine as my daily driver.
I also have a corporate/work laptop from Dell with 32GB RAM, 16 cores @ 4.x GHz etc. - a beast - but it runs Windows (+ antivirus, group policy crap etc.) and is slower in many aspects.
Sure I can compile a single file faster and spin up more pods/containers etc. on the Dell laptop, but I am usually not constrained on my T420.
I generally don’t spend much time waiting for my machine to finish things, compared to the time I spend e.g. writing text/code/whatever.
I learnt all I know about crypto from online resources. It’s perhaps a question of taste, so let’s just skip that one.
It’s all good that you can easily hash a password in PHP without knowing what happens[0]. If you need to interface with another language/program however, it’s not as convenient anymore.
I am a fan of understanding what you are doing. Also in crypto.
[0]: But not really though. You need to trust that the PHP-team is competent and understand security. They don’t have the best track record there IMHO.
Just a small comment/opinion on the inscrutability of crypto:
Crypto relies on number theory and a complexity theoretical assumption that N!=NP (i.e. that there exists one-way/trapdoor functions).
I think it is opaque by the very nature of how it works (math).
Understanding finite fields or elliptic curves (integer groups really) made me able to grok a lot of crypto. It is often a form of the discrete-logarithm problem somehow.
> I may be misinterpreting here, so please do correct me
I meant to say that being open source doesn’t automatically mean you can use the software commercially, hence the need for a liberal (enough) license (to permit you this option).
No ideology intended so to say :)
> Does the permissiveness of the license matter more than the utility of the tool?
No of course not. A useless, but free tool is still useless. Likewise I’d argue that a useful open source tool you can’t use commercially is equally useless to many.
> However, a lot of FOSS options would be much better off if consumers did contribute to the project
This is modus operandi for many acquisitions in the field of proprietary software.
If you have been in the business for a decade or two, you’ve seen this play more than a few times. It’s legal, it’s profitable, so it keeps happening. Even when it destroys valuable products in the end.
Open source software with permissive licensing is the only true guarantee of not getting squeezed.
But you can’t always find suitable FOSS etc. so here we are. It’s a sad situation IMO
I have used statistical models of volatility to improve execution prices.
It doesn’t require very advanced modeling to estimate a probability of e.g. getting filled at midprice (saving half the bid/ask spread) within a short time period.
Just basic Bayesian with a look-back window.
Execution cost is a big topic in the trading industry.
Plants on the contrary tolerate much more damage. To the point that we develop new species by bombarding seeds with ionized radiation.