"[T]hey measure peak performance, rather than sustained performance."
I never saw it expressed so succinctly. Excellent!
It captures well the frustration around tech interviews. You might be a very competent worker (sustained performance), but fail miserably during interviews (peak performance). Ideally, you could show a body of work during your interview, but this isn't possible with most commercial software companies. If you are lucky to work on open source for your job, it is easy to show your work.
To manufacture a public body of work for myself, I built two open source projects and published them on GitHub.
(Please do not read that as advice!) I can share and discuss them during interviews.
I also found another hint about their findings in this PDF written by Yarden's co-researcher Alex Ionescu: https://www.usenix.org/system/files/woot20_slides_ionescu.pd.... One of the slides specifically mentions the use of fuzzing tools to find these issues.
If there are other, better links I don't know about, please kindly share. :)
I can confirm Spotify GNU/Linux client appears to use libcef. I was surprised! I had read some old Internet posts that claimed Spotify GNU/Linux client was using Qt. (I have no idea about old versions of the GNU/Linux client.)
When I run command "ldd" on my Spotify GNU/Linux client binary, I see "libcef.so". And, I can see:
I agree. I cannot recall a single corporate password policy in my working life that did not require regular password resets. And now that I think about it, I am surprised that Google does not ask me to reset my password on a regular basis. I guess Google follows the latest NIST advice!
I have used that library on multiple projects for my job. It makes the code run about 50% slower, on average, because all the type checking is done at run-time. I am OK with the slow down because I don't use Python when I need speed. My "developer speed" was greatly improved with stricter types.
Finally, this isn't the first time I wrote a type checking library/framework. I did the same for Perl more than 10yrs ago. Unfortunately, that code is proprietary, so not open source. :( The abstract ideas were very similar. Our team was so frustrated with legacy Perl code, so I wrote a type checking library, and we slowly applied it to the code base. About two years later, it was much less painful!
I will try to read it!