Interesting reason which would explain the Selenium flakiness. It's just harder to write tests with race conditions using Playwright.

It's about time... I wish they would have gone for the AGPL + proprietary double license scheme instead of their odd licenses the last time.

A weird detour via baseball obscure rules to justify why we should pay attention to the "Highlander problem". This should be kept in mind especially for designing databases.

Definitely a good advice, I see very complex expressions in if (or while BTW) conditions way too often. They tend to accumulate over time.

Yes, such an arrest is concerning. Now, lots of people are voicing the wrong concerns... this article actually does a good job explaining it.

Here a good reminder that the PR of Telegram is highly misleading. It's not very secure, they don't really care about your privacy.

Interesting to see Typescript and Rust picking up pace slowly. Otherwise Python, Java, Javascript and C++ are still the big four overall. For jobs, C# and SQL are good to have in your tool belt.

Very good list of the challenges ahead for RSS as a popular protocol. It'd be great to see some of it being tackled.

I'm not sure the "bubble" comparison properly applies. Still there are indeed signs of the Open Source movement getting in troubles. It'll be all the more important to stick to the Free Software values.

How to avoid drowning in errors when getting serious about monitoring. Finding class of errors and treating them one by one will definitely help.

Looks like an interesting way to improve SQL. This feels like a nice extension, it's much better than throwing out the baby with the bathwater.

Interesting to see how far you can go preprocessing Python.

Interesting comparison between old attempts at backdooring OpenSSH and the latest xz attempt. There are lessons to be learned from this. It makes a good case for starting to sandbox everything.

Definitely something architects should do more. Understanding the business needs should be the input to the technical decisions. Otherwise you might just happily build the wrong thing.

Funny musing about the OOM killer. With nice pointers if you want to dive further into the topic.

SIMD is hard to use, not all problems can apply to it. But when they can, the performance gain can be great.

Starts like a satire, but there's a serious conclusion in the end. Indeed, mind the power dynamics in code reviews. Be nice, steer away from those antipatterns, especially since you might be on the receiving end the next time.

A little refresher about std::ref and std::cref. They come in handy sometimes, but also if you don't realize you need them you'll generate more copies than necessary.

Since they unfortunately turned on private attribution by default (why? Mozilla, why?). Here is an easy automated way to turn it off.

This is indeed a nice way to approach technical interviews. Unfortunately it requires quite some effort to setup and maintain. You also have to find the right bugs to put in the interview and this is a rarity.