@funkylab @KernelRecipes then read the lwn.net article instead: https://lwn.net/Articles/944300/ There's no lack of information about the CRA out there right now.

@gregkh on stage: Demystifying the Linux kernel security process #kr2023 - serious things coming...

@krzk @corbet @sjvn press releases will never be read by the people that actually need to know this anyway, so we aren't going to go down that path :)

@corbet @sjvn Send the emails my way, no one seems to ever actually want to talk to _me_ about these support dates for some odd reason...

So OSS Europe was an interesting experience, this year, in a way.

I did my usual talk, and started with the usual section on kernel releases. When talking about stable updates I tossed in a quick mention that six-year support from the stable team was being phased out — something I understood to be generally known for about the last year. Way at the end of the talk, as my last topic, I discussed at some length the stresses being felt by kernel maintainers.

@sjvn wrote an article about the talk (https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be-cut-as-maintainence-remains-under-strain/) and made a connection between the stable-policy change and the maintainer issue — something I had not done in the talk. It was a bit of a shift from what I said, but not a bad article overall.

Then the rest of the net filled up with other writers putting up articles that were clearly just cribbed from SJVN's piece — sometimes with credit, sometimes without. I'm getting emails about what a terrible idea this all is, as if I had anything to do with that decision or can somehow change it. I have, it seems, taken away everybody's six-year support, and they're not happy about it.

All because of a 30-second mention of a change that was made public something like a year ago. My 1.5 minutes of fame has given me a new appreciation for this old quote from Rusty Russell: "when a respected information source covers something where you have on-the-ground experience, the result is often to make you wonder how much fecal matter you've swallowed in areas outside your own expertise."

@zev @monsieuricon That was my fault, my scripts didn't like the long latency of attempting to send emails while going through the chunnel and so the lockfile expired and decided to spawn a bunch of retries to resend the emails.

I disabled that for the return trip, and all is now good, apologies for the multiple messages, this seems to happen to me every few years...

@alwayscurious @andreasdotorg @badger Linux is a great fit for safety critical code, as is proven in many many installations of it in those types of systems in the world today. It all depends on the infrastructure around it, which is the same for any other choice of software at this level.

@alwayscurious That is not what I am saying at all. You need to understand your usage model and know just exactly what portions of the kernel you are using and design your update schedule around that.

And be prepared to update/reboot at any point in time, after properly testing updates.

Companies using Linux in their "uptime-critical" products usually already know all of this and can handle it just fine. If not, then they are designed and supported wrong and that's a company problem, not a Linux problem.

@jakub Why do you need an ID before the bug is fixed?

Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:

- The kernel security team does not have any "early notice"
announcement list for security fixes for anyone, as that would only
make things more insecure for everyone.

- The kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

- You HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random
patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system,
and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss
it with them as to how they achieve this result as this is what you
are paying for. If you aren't paying for it, just use Debian, they
know what they are doing and track the stable kernels and have a
larger installed base than any other Linux distro. For embedded,
use Yocto, they track the stable releases, or keep your own
buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before
putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about
1.5mil lines of code, embedded runs about 3.5mil lines of code, your
mileage will vary). If you can't test releases before moving them
into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a
future problem as future problems, when found, will be fixed then.

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...

@krzk @sj Also note that the largest generator of CVEs for the kernel is RH doing so for their kapot engineering process which requires a CVE to be created to backport a patch easier to their old "enterprise" kernel tree. That means they are usually creating new CVEs for issues we fixed months/years ago. Hopefully one day they fix their process (I document it in detail in the presentation @krzk linked to above).

When your server is doing too many builds at once...

@Foxboron @torvalds Like perhaps this one: https://lore.kernel.org/r/20230817204523.never.034-kees@kernel.org

@Foxboron @torvalds I would, but it's not for a subsystem I maintain, sorry. Try finding something that I am responsible for and I'll be glad to take it.

@niclas @Foxboron @torvalds To quote the GPLv2:

"The source code for a work means the preferred form of the work for making modifications to it."

I doubt printouts are how you handle the source in a way that you are able to make modifications to it :)

@dvzrv @Foxboron @torvalds Kernel patch reviews are almost always better done with drinks. Calms the reviewer into not getting as upset as they normally would...

@Foxboron @torvalds Oh, and bonus points for the dot-matrix printer with the perforated paper! That shows dedication to both keeping such a beast alive with a working ribbon, as well as having paper for the thing.

@dvzrv @Foxboron @torvalds There is way more stuff in the kernel that started out over drinks with "I bet you couldn't do that!" than we would like to admit, so you are continuing a long and proud tradition!

@Foxboron @torvalds If you can import that into git, I will be impressed :)

On the always good https://kottke.org/ the other day, there was a link to a series of videos of professional drummers hearing songs for the first time, without the drum track, and then playing what they think would fit. Here's one of them, https://www.youtube.com/watch?v=tbUYVcaF_l0 and while I'm not a drummer, the best part of this is how Dirk Verbeuren explains the process of listening to the song, and how to learn something never seen before and how to adapt to it. The whole series is recommended: https://www.youtube.com/playlist?list=PLThYwnIoLwyWiF5RgHPzOzYNdqQw1-tep

Anyway, got me to thinking, a while ago a friend (also a kernel developer) had the idea of a presentation for the yearly Kernel Recipes conference that would be him sending me a patch, me reviewing it, talking about how it is reviewed, and the back and forth between us on getting it into a mergable state. That process is one that someone else recently asked me "what presentations can you recommend for new kernel developers to explain how this review process works" and I didn't have any suggestions, but it really is an important thing that is not taught at all in school, or in any company that I know of.

So maybe, a series of videos, or talks, where a maintainer gets a patch series and walks through how they review it, what they look for, what they expect, and how its tested (if at all), might be interesting? Or "here's a reported bug, how do you debug it?" type of presentation to put a developer through the steps of attacking something unknown, and figuring out what the problem is, and how it could possibly be solved.

Brings me back to the days of the Plumbers conference session where we had "bring us your laptop and we will get suspend/resume to work on it" tracks that ended up being a lot of fun for everyone involved as crazy hardware/bios issues were debugged live.

Would this even be interesting? I think it might need a lot of good editing, you don't want to see me staring numly at a terminal window for a few hours while reading lots of inscrutable driver code tracing it to find a bug, that would put everyone to sleep...