kevinarpe

Nice! Thanks for the last paragraph about "Dietland". I found a Wiki page about it here: https://en.wikipedia.org/wiki/Dietland

I will try to read it!

Thank you to share. If you have time, can you add links to other stories that caught your attention? I would like to read more!

"[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 tried Googling to find this blog post. Did you mean to write Yarden Shafir? If yes, maybe it was this blog post? https://windows-internals.com/printdemon-cve-2020-1048/

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:

$ ls -l /usr/share/spotify/libcef.so

-rw-rw-r-- 1 root root 147980856 Sep 15 06:13 /usr/share/spotify/libcef.so

That's a big library!

I am not a security expert, but this looks pretty useful: https://security.stackexchange.com/questions/193351/in-2018-...

And that Twitter link (https://twitter.com/TerahashCorp/status/1155129705034653698) leads here: https://www.password-hashing.net/ ... but, on that website, I could not find an explanation about why to use argon2 over bcrypt.

This PDF is dated June 2017: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

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!

(For other readers: It seems that quote comes from here: https://en.wikipedia.org/wiki/Password_policy)

I also struggle with weak(er) typing in Python, compared to strong(er) typing in C++, Java, or C# -- or even VBA(!).

Frustrated like you, I wrote my own open source type checking library for Python. You might be interested to read about it here: https://github.com/kevinarpe/kevinarpe-rambutan3/blob/master...

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!