Linus will not be merging any code from systemd developer • Hacker News Board

Re: Linus will not be merging any code from systemd developer

#41

Post by tdsamardzhiev » Sat, Apr 05, 2014, 6:45 AM UTC

PhasmaFelis wrote: post #25

userbinator wrote: post #7

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.

...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, s…

Read his G+ reply. Why on the Earth would one want to work with that guy anyway?

Re: Linus will not be merging any code from systemd developer

#42

Post by tdsamardzhiev » Sat, Apr 05, 2014, 6:58 AM UTC

programmer_dude wrote: post #13

darkarmani wrote: post #10

Earlier quoted context omitted.

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.

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.

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

Re: Linus will not be merging any code from systemd developer

#43

Post by mantrax4 » Sat, Apr 05, 2014, 7:12 AM UTC

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

Re: Linus will not be merging any code from systemd developer

#44

Post by mantrax4 » Sat, Apr 05, 2014, 7:40 AM UTC

dkarapetyan wrote: post #34

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.

Have you seriously not witnessed an online fight over tabs vs spaces so far? Or braces style?

It doesn't matter what it's about. It's just an excuse for this:

http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8b...

Re: Linus will not be merging any code from systemd developer

#45

Post by ZeroGravitas » Sat, Apr 05, 2014, 7:55 AM UTC

mantrax4 wrote: post #43

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-tr…

Good overview, but the kick off was that a simple bug in systemd was flooding the kernel log. Rather than ask for that bug to be fixed (possibly assuming it was intended behaviour) they asked for systemd to ignore a flag that is expressly designed to be read by things other than the kernel.

The fact that the original flood of messages was as simple bug renders the whole "territorial pissing" thing somewhat more pathetic than it appears at first.

Re: Linus will not be merging any code from systemd developer

#46

Post by neumann » Sat, Apr 05, 2014, 8:04 AM UTC

burntsushi wrote: post #32

Workaphobia wrote: post #24

Earlier quoted context omitted.

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?

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.

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.

Re: Linus will not be merging any code from systemd developer

#47

Post by papaf » Sat, Apr 05, 2014, 8:23 AM UTC

akira2501 wrote: post #12

dredmorbius wrote: post #6

Earlier quoted context omitted.

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.

They're fucking around well beyond PID 1. Default binary log formats. This odd binary messaging bus with god awful reverse domain names, a shifting binary protocol format that injects itself into the kernels standard text-based messaging formats. I find the whole dependency system completely bizarre, because to truly implement it, you have to hook into _everything_ and make it part of this odd binary mess they've cre…

They also took over core dumps.

   ulimit -c unlimited

It just fails siliently now. The priesthood have determined that it is better to run:

   systemd-coredumpctl

This annoyed me because if I wanted to do internet searches to achieve simple things I would be using another OS.

Re: Linus will not be merging any code from systemd developer

#48

Post by Sammi » Sat, Apr 05, 2014, 12:27 PM UTC

demallien wrote: post #39

userbinator wrote: post #7

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.

I tend to think of Linus as being similar to Steve Jobs - brilliant but arrogant srseholes whose products I enjoy using, but I would never work with them without some very serious compensation for putting up with the shit. Which is where this becomes a problem for Linus. Jobs could hey away with it, because he could pay people enough that they accepted the bad treatment. Linus, not so much. It's clear that that the k…

No you're not getting it. Linus is not like this often. And he's not like this to people who are innocent bystanders. Linus will only chew you up if you're an engineer he knows personally that should know better.

What you have to understand is that these people are not on Linus' payroll, so he has little direct power over them. Screaming at people is one of only two forms of power that Linux can exert, the other being withholding merging of code, which is even more extreme. And these incidents actually come up rather seldom when you think about how much code is submitted to the Linux kernel, which I think is a testament to how well Linus' management is working.

Re: Linus will not be merging any code from systemd developer

#49

Post by programmer_dude » Sat, Apr 05, 2014, 12:51 PM UTC

tdsamardzhiev wrote: post #42

programmer_dude wrote: post #13

Earlier quoted context omitted.

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.

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

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.

Re: Linus will not be merging any code from systemd developer

#50

Post by programmer_dude » Sat, Apr 05, 2014, 1:20 PM UTC

Rantenki wrote: post #20

programmer_dude wrote: post #13

Earlier quoted context omitted.

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.

While it would be nice for the kernel to handle any kind of bad behaviour by default, it isn't always realistic. I mean, it would be nice if the kernel by default could handle a simple forkbomb, but it doesn't without restricting your limits.conf fairly severely. You can blow up the system in a variety of ways that are outside of the kernel's responsibility. It's not up to the kernel devs to hack around your bad beha…

Please see my response to tdsamardzhiev. I have replied to some of your points there. I agree this borders on bad behaviour since the author knows the kernel does not have rate limiting in place. Ideally he should have put in a feature request with the kernel devs and should have self regulated the log traffic using some workaround (like checking for debug.systemd) until the kernel stepped up its game. If I were Linus I would have taken this up as a challenge (as I am sure he will too).