The 'update all the things all the time, maybe there will be regressions, but hey vendors should fix' em' is maybe hearable from a cloud-continuous-delivery standpoint, but not everyone can and should do that. And getting fixes also comes its lot of new features with their unchecked security surfaces, enabled by default...

What I'm also hearing here is 'vendors shouldn't work on their branch but contribute to main/stable branches' and I'm here wondering how you can ever ship anything tested (since it's part of the subject) with this lack of control of branch history. Starting from something you know works, and increasingly upgrade/fix is the only manageable way to ship something as complex and untested as upstream Linux.

The solution is 'add 4 guys to your team and fix our coders' bugs before they ship'? So, fun coding and good PR for some, drudge of shitbugs and abuse on lkml for others.

> This "upstream first" approach to product kernel development and testing is extremely efficient. Google has been successfully doing this with Chrome OS and Android for a while now, and is hardly alone in the industry.

This seems to be conflating testing a product against an upstream kernel and making your stable Linux distribution use an upstream kernel. A huge number of open source projects and vendors already do the first thing without any difficulty. I believe that doing the second thing is much rarer. Do Google do both things?

I used to put main kernels compiled for a very standard distro, on production, and manually updated twice a month after testing a bit each release.

  * One time I dodged a data corruption bug with a default, common filesystem, that obviously got rapidly patched.
  * Last time and very recently, main kernel introduced a bug that made NFS just don't work for clients trying to connect, until a patch was released and applied for those servers.

On the other hand, also saw a vendor mainstream bogus update that rendered the boxes unpingable after a reboot. Could patch before a reboot was needed so day saved.

You're almost never safe. But I agree some testing helps. Anyway not everyone has the infra and/or resources.

Feel free to start with asking engineers more security related questions, cuz you know - poorly performing algo can be rewritten meanwhile leak cannot be reverted

https://www.linuxfoundation.org/press-release/google-funds-l... Maybe Google could offer to fund 20% of a bug fixing dept. If Huawei, Intel, Samsung, AMD, and Google each put up 20 employees, it could get done.