Hmm, I was expecting "Sorry we made a mistake, we'll switch the option to systemd.debug".<p>> At that point there is simply no other option for that, because persistent storage is not available<p>This was about overloading an already used option by another team building a core system component -- the kernel. A debug for kernel's command line is for the kernel.<p>> It's the option an admin can specify which tells him why the system doesnt boot,<p>Ok so he does and now his system also doesn't boot but now it is either because of the original problem or because it gets flooded by systemd logs.<p>And then, he goes and posts to the kernel mailing lists saying how kernel is a piece of shit.<p>> That turns this into some kind of power game, which I am totally not interested in.<p>also<p>> We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail.<p>I think due to their attitude towards both testing, towards the kernel community, they shouldn't be building core system components. And did he just write that kernel is just "an implementation detail?".<p>Maybe systemd was a mistake. Integrating and dumping socket acceptors, logging, and the whole kitchen sink into one component. So when it breaks it really breaks.
Google+ really doesn't get retweeting, does it. That whole post is written by someone who isn't the one in the photos at the top. A single "originally shared" link points to the original.<p>Retweeting was a genius move by twitter, a post by someone you don't follow appears in your timeline and it looks like any other and attribution is perfectly captured.
I have a fair amount of experience with Linux, but I'm a little lost by what's going on here. Can someone out there dumb this down a bit for an init newbie?
I wonder how this whole thing would have gone down if the original bug report had simply described the problem rather than demanded their preferred solution to what they thought the problem was.<p>Linus and others keep acting like the bug was "systemd floods the kernel logs when I pass the debug flag" but it was actually it was "Do not parse "debug" command line ".<p>The obvious answer to the first is " Sorry about that, the bug is fixed in master branch".<p>The obvious answer to the second is "No, that's what it's for"
to be clear (I am not english). Ratelimit means drop some logs. Lennart Poettering is commplaining because he wants the kernel to be happy with him flooding the kernel with logs.<p>When I debug software, I do not want to lose logs and I do not want software to produce so much logs it is impossible to use.
I am surprised by the hostility displayed by the systemd guys. I was expecting them to admit they were wrong, and things would be back on track.<p>With such a reply, I wonder what effect will this have on kdbus making forays into the kernel (not that I am looking forward to it ;).
"Here's a nice note for all the reporters who are emailing me, go suck it."<p>"Yes it's titillating, and drives page views, but really, is that the best use of an Liberal Arts degree?"<p>Ah, the perfect guy to represent our profession.
>Correct. I don't mind people piggy-backing on some fairly obvious generic term like "debug" per se. I don't know if the old init scripts did that, but I do know they did it for "quiet", which is basically the reverse of "debug".<p>>What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug.<p>So Torvalds is saying he doesn't like dictatorial project maintainers who reply in an abrupt and abrasive manner to contributors? He is so concerned about the lack of politeness and professional discourse that he just had to raise this issue? Hilarious.