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

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

#51

Post by darkarmani » Sat, Apr 05, 2014, 1:21 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…

> I wonder if Kay would have been more open to accepting change requests to systemd without Linus's bad behaviour. It bears thinking about...

Why is Linus' behavior in response to crap like this bad?

> Kay: "Again, move discussions to the mailing list; this is a bug tracker, but there is no bug to track or fix here."

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

#52

Post by sixbrx » Sat, Apr 05, 2014, 3:41 PM 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…

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

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

#53

Post by Workaphobia » Sat, Apr 05, 2014, 3:41 PM UTC

jafaku wrote: post #36

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?

Why not give it another try now then? I have used it for years and, unlike windows, I never had to reinstall it just because something broke. And things only broke when I messed around with them, but it was always fixable. If you also use virtual machines or linux containers you will never break anything.

I intend to dual boot next time I upgrade laptops, so we'll see. I absolutely loved the customizability of the desktop environments.

But I hated worrying about graphics drivers, updates, xorg.conf, automake, and finagling my system configuration to get source tarballs to compile.

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

#54

Post by MBCook » Sat, Apr 05, 2014, 4:01 PM 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.

If you read through the kernel thread, it seems that's exactly what they're doing.

While systemd is obviously doing something stupid, no userspace program should be able to dump so much to the log that the machine becomes unusable. It seems like they were going to apply per-file descriptor limiting the way to they seem to limit in kernel logs on a per-log site basis.

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

#55

Post by rsanders » Sat, Apr 05, 2014, 4:16 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.

The kernel does quite a lot of work to prevent user-space programs from doing stupid stuff to each other, or to at least ameliorate the impact of such stupidity. One of the Unix philosophies has always been to prevent a runaway program from rendering the system inoperable.

systemd has apparently elevated itself somewhat above the typical "user space" level, but it's still not a bad idea to harden the interface between systemd and the kernel where possible.

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

#56

Post by dredmorbius » Sat, Apr 05, 2014, 6:20 PM 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…

Oh, I know. Which again is why I'm as concerned as I am.

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

#57

Post by demallien » Sat, Apr 05, 2014, 8:16 PM UTC

darkarmani wrote: post #51

demallien wrote: post #39

Earlier quoted context omitted.

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…

> I wonder if Kay would have been more open to accepting change requests to systemd without Linus's bad behaviour. It bears thinking about... Why is Linus' behavior in response to crap like this bad? > Kay: "Again, move discussions to the mailing list; this is a bug tracker, but there is no bug to track or fix here."

Because as with many things, it's a matter of perspective. For Kay, this code works as intended. So if you want him to change it, don't open a bug, discuss it on the mailing list. This does not seem like a completely unreasonable request on Kay's part. Note also that Kay does not get personal in this response. Compare and contrast with Linus then calling Kay a "fking primadonna". Now, whether you agree with Kay or not, do you really think that Linus's approach is going to get him what he wants?

Again, I have the greatest respect for Linus's achievements, but I personally feel that he uses the power those achievements have bought him to be a bully, and that gets no respect from me.

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

#58

Post by tetha » Sat, Apr 05, 2014, 9:32 PM 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…

Then again, a hard question is: Do we want developers with problematic habits working on the linux kernel?

I'd put the core linux system into a situation special enough to make it the correct decision to toss everyone but the best of the best of the linus-compatible developers out. It's not a pretty decision, but after a certain point of importance, I can understand that decision.

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

#59

Post by SamReidHughes » Sat, Apr 05, 2014, 11:58 PM 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.

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.