Linus will not be merging any code from systemd developer

Linus will not be merging any code from Kay Sievers into the kernel until Kay changes his pattern of not fixing problems in code he previously submitted.

Wow. This comment captures it best:

> "Hmm, a user adds to the kernel command line "debug" and systemd starts spitting out so much crap that the system doesn't boot anymore? That sounds like a major regression to me. Note this is a kernel command line, not a systemd command line. Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.

> This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it."

And I really, really wish Ubuntu had held out with upstart instead. We need the alternative.

You don't cavilierly fuck with PID 1, and that's precisely what the systemd folk appear to be doing.

I'm really hoping Linus's rant makes an impact on them.

Early in the thread Linus explains it:

It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.

It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same f*cking primadonna involved.

Steven, Borislav, one thing that strikes me might be a good idea is to limit the amount of non-kernel noise in dmesg. We already have the concept of rate-limiting various spammy internal kernel messages for when device drivers misbehave etc. Maybe we can just add rate-limiting to the interfaces that add messages to the kernel buffers, and work around this problem that way instead while waiting for Gregs fix to percolate? Or are the systemd debug messages going to so many other places too that that wouldn't really help?

          Linus

They then went into a rate limiting discussion. Later in the thread it seems to have come up again, leading to the post 0x006A summarized.

Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.