Hacker News Reader

Comment by simondedalus | Hacker News Reader

I don't want to argue about systemd vs this or that, but re: (2) you are totally misrepresenting linus's objection to systemd (developers).

the well-publicized incident to which you're referring had systemd introduce something that broke userland, then instead of fixing it in systemd code, proposed a kernel change for it. this is, obviously, bad practice.

it would be one thing if the systemd code exposed a vulnerability or inefficiency in the linux kernel. but fixing your bad code by modifying the kernel is like trying to modify a popular compiler because some bad code you wrote isn't doing what you want it to.

View on HN

I wasn't referring to any particular systemd thread (my experience has been watching Linux/Linus in the context of ARM), but I think you are referring to the post by semi-extrinsic and this thread: https://lkml.org/lkml/2014/4/2/420

I examined that thread, and the upshot seems to be that the kernel wasn't rate limiting logging so userland could break the kernel. And Linus threw a hissy fit instead of actually examining the situation. The kernel not rate limiting is a fault in the kernel. The fact that a user program exposes it does not mean that the user program is the one in the wrong. And Sievers basically said: "Not rate limiting logging is a kernel problem. We're going to make you fix it." So, basically he had the temerity to both A) pull a political power play and B) be technically correct--and it pissed Linus off ferociously.

Linus, however, is fighting with the 800lb gorilla. That's not a good position to be in. Linus needs the RedHat programmers more than the RedHat programmers need Linus. They'll keep Linus around to avoid the bad PR that would come with a fork, but, if he gets in the way, they'll just cut him out of the loop.

I think the way you did. Many things in systemd aren't as good as they should be. However it's working and does his job. The issue that raised up here is definitly a problem in the kernel. I mean it's not a good practice that other programs could flood yours. However the problem whey they argued that so hard is caused by the fact that both parties trying to fight a political war over the linux ecosystem which is just bad, kay sievers also said it. They make a project that can only be good if all parties, kernel, init, gui, are playing together and not fighting against each other like childish politicans.

> And Linus threw a hissy fit instead of actually examining the situation.

You really, really, really need to take ten minutes or so and read the whole thread. If you've not the time for that, then the single message linked here provides a decent amount of context: https://news.ycombinator.com/item?id=10484317

I did read the thread before I even posted, thanks.

Linus' first reaction to systemd accidentally flooding the kmesg queue was to make an ad hominem flame directly at another developer when the kernel was responsible for at least half the problem (lack of rate limiting).

Most people would qualify that as "throwing a hissy fit".

> Linus' first reaction to systemd accidentally flooding the kmesg queue was to make an ad hominem flame...

Are you talking about this?

"Key, I'm fcking tired of the fact that you don't fix problems in the code you* write, so that the kernel then has to work around the problems you cause."

If you are, then you have to know that he said that because Sievers has a history of aggressively refusing to own up to (and fix(!)) the bugs he introduces into his code. [0] Contrary to popular understanding, Torvalds doesn't dress down people unless they've demonstrated that they should know better and continue to fail to meet their demonstrated potential.

Most people call that sort of management style "stern" and "meritocratic".

[0] Indeed, it is this behavior that led to Sievers's Linux kernel commit bit being unset. Because of this, Greg-KH had to become the front-man and shepherd for the kdbus project.

Reply on news.ycombinator.com