Remember that blog post "How I got robbed of my first kernel contribution" where a maintainer slightly rewrote a patch and took credit for it? Well, I decided to do something about it.
I co-authored a guide with Maria Matějka and some other folks on documenting how your project gives credit and otherwise handles contributions. If your project's policy is to lightly rewrite contributions and take credit for them, say so! Subscriber link (free) to the LWN article:
I'll be co-presenting tomorrow evening on our Bike Bus, including last week's ride with the brass band. If you're in the area, Somerville's Aeronaut Brewery, 6-7:30PM, come say hi! https://www.facebook.com/events/453905903669468
Interested to learn more? https://docs.google.com/forms/d/e/1FAIpQLScXN6zhH9dkISgsvGsgHH53k_zN3EdOgxQc8JHPTwpHUUbPaQ/viewform
Now you might wonder: how often does this actually happen? The common wisdom on this topic is that hardware failures are so rare that software bugs will always dwarf them. As I found out this is demonstrably false.
While investigating Firefox crashes I've come to the conclusion that several of the most common issues we were dealing with were likely caused by flaky hardware. This led me to come up with a simple heuristic to detect crashes potentially caused by bit-flips. 10/17
Hey Mastodon friends, it's Bike Month so we're running a discount in our official store. 10% off on everything, including apparel and stickers.
Use code BIKEMONTH at checkout.
We rely on listener support to keep the podcast going and this is another way we keep the lights on.
Thanks for your support!
Mentioned this in passing, but want to publicly thank Dell for sponsoring a big test box. Tons of storage, tons of bandwidth, and now 100G connected in my little lab for great io_uring networking testing as well. They even stopped by my office for a day to rack mount it!