

Linus will not be merging any code from systemd developer - mtct
http://permalink.gmane.org/gmane.linux.kernel/1677152

======
e12e
Oh, the actual bugzilla thread is (if possible) even more depressing:

[https://bugs.freedesktop.org/show_bug.cgi?id=76935](https://bugs.freedesktop.org/show_bug.cgi?id=76935)

I had actually started to warm to the idea of systemd, thinking that it
couldn't end up the same clusterf*ck of mismatched reinventions that didn't
really solve any problems that pulseaudio was. I guess it's time to move to
Debian/kFreeBSD and ignore this crap.

~~~
ww520
After reading that, I won't fault Linus in blowing up.

------
csmattryder
Systemd is soon to be integrated as the default init daemon for Ubuntu, one of
the most user-friendly Linux distributions available.

It worries me that Sievers, and the systemd team aren't approaching testing
with an almost paranoid attitude. Linux is finally getting a foothold in
consumer desktops, it'd be a shame for people to go back to other operating
systems purely because "it broke one day, something about systemd".

~~~
Workaphobia
I haven't used linux on a desktop in several years, but my experience was that
"it broke many days, something about everything". Why should this one
component be held on a pedestal as make-or-break for the whole OS? Is a broken
init daemon worse than a broken xorg.conf from a desktop user's perspective?

~~~
burntsushi
As you said, you haven't used the Linux desktop in many years. It's come a
long way in that time.

For example, editing your xorg.conf is virtually a thing of the past these
days. I haven't touched it in years and run a fancy triple monitor setup.

~~~
neumann
right up until a ubuntu kernel update breaks the binary gpu driver, and you
spend the next two days trying to figure out which binary or open source
driver allows you to run everything the way you were at the beginning of the
week. Repeat this every 6 months.

------
darkarmani
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."

~~~
shawnz
> Userspace tools should not be using the same kernel parameters that are
> defined by the kernel. That's just broken and wrong.

My understanding is that this is not the issue and, in fact, the command line
parameters are provided to userspace in the way that they are exactly so that
applications can do this kind of thing.

Rather, the real issue is that the flag IS commonly used this way, and
systemd's response to it being set was so aggressive that it prevented it from
being used for anything else. A not-uncommonly-used system configuration,
having "debug" set, was being broken unnecessarily and in an unintuitive way.

~~~
darkarmani
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.

~~~
programmer_dude
I think as always the kernel should be made robust enough (in this case
through rate limiting) to handle such abuse.

In a way this Sievers guy is right but he could have been more polite in
asking the kernel devs for this feature. And he needs to co-operate by cutting
down the log traffic until the kernel is fixed.

~~~
tdsamardzhiev
I disagree - it's not the kernel's job to prevent user-space programs from
doing stupid stuff.

~~~
programmer_dude
I think it is. It is the kernel's job to protect itself from user-space
mischief. It always has been. For example why are processes isolated from each
other? Why does it guard against invalid memory/resource accesses etc? The
kernel should be able to protect itself from denial of service attacks and
must remain functional at all costs. A fork bomb is equally bad it is no
excuse for the current failure mode.

BTW Linus agrees rate limiting is desirable here. This is the reason why I
said systemd has to hold off its fire hose until the kernel can take care of
it.

------
0x006A
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.

~~~
MBCook
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.

------
userbinator
Although I've heard a lot of others disagree, I like the fact that Linus'
posts are straight and to the point. No sugar-coating or euphemisms, just
telling the hard reality like it is.

~~~
PhasmaFelis
...Is a good way to turn otherwise-skilled people with some problematic but
fixable habits into people who refuse to work with you ever again.

Brutal honesty works with computers, but it's not always the best policy for
keeping humans productive. Linus gets away with it because he's a celebrity,
and moreover the right kind of celebrity. These comments would look very
different if the public mockery was coming from, say, Steve Jobs.

~~~
mbreese
He's been this way long before he was a celebrity coder. This is just how he
runs Linux, and I think that is evidence enough that the process works for
him.

The team itself might be a self-selecting group of people who can work with
Linus. But, overall, I'd say that his brutal honesty works "well enough". It
might not be a good way to run a corporate project, but for an OS kernel, the
benevolent dictator model seems to work pretty well.

I wonder how the kernel groups at Apple and Microsoft work though... or how
FreeBSD is organized... that'd be an interesting comparison.

------
mcescalante
For anyone interested in what ensued, Greg KH submitted a patch to systemd to
fix this issue. Linus then replied (among some other words) to Greg's
confirmation of his patch with:

"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."

------
jonalmeida
This is quite confusing after reading Sievers' reply on Google+ (third comment
on the post) [1]

> my last kernel patch is more than a year old, my last non-trivial kernel
> patch 2 years old. i stopped working on the upstream kernel "long ago" for
> reasons i cannot stand the attitude of these guys, i decided to work with
> grown up or funny, or grown up and funny people instead and i enjoy it a lot
> more. not sure what this childish blackmail attempt relates to.﻿

[1]:
[https://plus.google.com/108087225644395745666/posts/3cWXzYqB...](https://plus.google.com/108087225644395745666/posts/3cWXzYqB6MB)

~~~
rwmj
I'm guessing Linus is referring to udev (which is broadly tied to the kernel).
For no good reason, udev -- a separate daemon -- was pulled into systemd.

------
duked
this links provide a better context on the attitude of the systemd developer:
[https://bugs.freedesktop.org/show_bug.cgi?id=76935](https://bugs.freedesktop.org/show_bug.cgi?id=76935)

------
estebanrules
Seems reasonable to me.

------
dkarapetyan
I don't get why there are so many egos in kernel and low-level development
circles. I get that it's a bit more challenging than usual application
development but the egos seem way too big relative to what's involved.

~~~
SamReidHughes
The reason is, in the typical contentious low-level development human
interaction, one developer is an idiot with insane scrublord opinions, while
the other isn't. So the first developer has an inflated ego, and the second
doesn't, and people standing on the side who don't have a clue which is which.
In this case, we have one who thinks it's reasonable for the debug flag to
bring down the system, and the other is a sane reasonable person who's not
going to tolerate this crash-the-planet type behavior any more.

------
NotKaySievers
I was looking at devkmsg_open() because of Linus's patch, and I noticed that
user->prev initialization is missing in that function and a few other places
where seq/idx gets reset.

This is at best a minor bug since it only affects the first line read from
/dev/kmsg, but I thought I'd point it out if anyone wants to fix it.

------
mantrax4
The nerd fight tl;dr so far:

\- Kay claims a system not booting due to a casual kernel log flood from
systemd is not an issue.

\- Linus agrees the "debug" flag (along with other generic kernel flags)
_should_ be used by services like systemd, yet blasts Kay for using it,
because it "usually isn't a problem", but here "it's a problem".

\- Linus threatens not to accept kernel patches from Kay.

\- Kay has not written a non-trivial kernel patch for over two years, and
doesn't want to write any.

\- Linus agrees rate limiting should be applied on the kernel's side, but
that's not a solution somehow here, because reasons.

\- Kay says Linus is involved in a "childish power play".

\- Linus calls Kay a "primadonna who thinks the world revolves around him".

In short:
[http://media.giphy.com/media/6HFUDKwlWcAbC/giphy.gif](http://media.giphy.com/media/6HFUDKwlWcAbC/giphy.gif)

~~~
sixbrx
"\- Linus agrees rate limiting should be applied on the kernel's side, but
that's not a solution somehow here, because reasons."

Wouldn't it be better for the entity writing the messages to prioritize them
and select the most relevant so that it doesn't write so many that the system
cannot start, rather than let an entity that doesn't know the meaning of the
messages arbitrarily discard most of them?

Rate limiting seems a last resort not a proper solution.

