443 karma · joined December 6, 2016
> intentionally designed to yield hard to read code
I think if you assume that syntax you find odd/difficult was intended to confound you, I can safely make assumptions of my own.
That's entirely the opposite from my experience. Rust is a pleasure to code in for personal projects once you're familiar with the language, especially compared to C/C++. Managing dependencies is more straightforward, and there are a lot of crates out there to make writing your project easier.
In some languages it might fall under the realm of "undefined behavior" (in that it compiles/validates syntactically but will likely blow up at runtime), though most linters for even those languages warn you about that. Alternatively, it might define a precedence for you, avoiding the need for parens.
This page gives more explanation than the landing page does I think
bro what on earth are you on about
General chance of being in either group: 50% (10 people with autism, 10 with ADHD, 20 total).
Chance of having autism if you have ADHD: 50% (9 with autism, 9 without, 10 total).
Chance of having ADHD if you have autism: 90% (9 with ADHD, 9 without, 10 total).
https://en.wikipedia.org/wiki/ARM_big.LITTLE#Heterogeneous_m...
https://en.wikipedia.org/wiki/Heterogeneous_computing
It even lists big.LITTLE there as a typical example in the second article. big.LITTLE itself never had different ISAs as far as I could tell, just scheduling caveats that lead to efficiency tradeoffs, like the first article mentions.
A bit of googling around was able to shore up a bit more information on the bFLT format:
1. The source of the text on the page linked: https://web.archive.org/web/20120301074213/https://retired.b...
2. Notes from someone looking to implement a bFLT loader for homebrew: https://blog.tangrs.id.au/2012/04/07/bflt-format-implementat...
The TPM measures everything that you feed it. The firmware feeds it whatever binaries it boots, and those binaries may in turn feed it other data (configuration, chainloaded kernels, initrd, etc). Just booting a live disk on a TPM-encrypted computer won't be sufficient to access the data, as the loaded binaries/kernel arguments/etc will be different, so the TPM measurements will b e different. As such, it won't unlock.
The problem here is that the TPM doesn't measure things running in Linux (at least, not by default), so it doesn't know the difference between "expected initrd booting correctly" and "expected initrd being exploited".
Might not matter for the things you care about, but some people certainly do care about boot performance.