Comment Re:Gnome3, systemd etc. (Score 1) 450
Actually, that was a valid technical argument. You just disagree, but you don't even have the decency to admit it.
Actually, that was a valid technical argument. You just disagree, but you don't even have the decency to admit it.
No. Systemd supporters give plenty of technical reasons for their support. In my case (for one thing) it is wanting event based processing of service management. Systemd offers that, sysV rc doesn't. Like it or not, that's a technical reason.
On the other hand, you anti guys keep bringing up things like this shit, or 'not Unix philosophy', or 'monolithic hairball'. Those are not technical arguments.
Do me a favour, and refrain from answering until you can actually muster a technical argument against systemd.
Once again you just disregard already given information. I summarized the bug and the related posts, but since you are going to whine regardless, I'll have Jonathan Corbet of LWN do the honours.
His article has all the links, to the bug and the related discussion. Of course you are going to cherry pick single posts again, but at least the peanut gallery will get to see who is being disingenuous here.
And this is my last word in this entire discussion. I have nothing to prove; you just have to show that you can do more than cherry pick to justify your irrational hatreds.
No. The discussion of Kay Siever's undiplomatic initial handling of the bug split off from the main thread. Kay has been put under supervision of Greg KH, and that was it.
After that, the kernel devs and the systemd devs produced a solution.
Again, you're cherry-picking posts to support your worldview, disregarding all else, and projecting your dishonesty on others. As I said: Liar.
No, you did not refute my claim. You ignored the entire bug, focusing just on Lennart's final conclusion. That's cherry picking.
Seeing as that the bug report, the LKML and systemd mailing lists came up with a full solution of the bug, you are a liar if you say that the systemd devs don't fix bugs.
Here's the full solution: using the generic 'debug' parameter of the kernel command line to turn on systemd debugging is the correct way to use that parameter, as stated by Linus himself. What is incorrect is generating too much logging for the kernel message buffer; this problem is fixed by fixing the original assert bug in systemd, and by Lennart's design decision to defer as much logging as possible until userspace is up.
It's all there in the bug and related discussion. You refuted nothing. You are a liar. And an Internet blowhard, a keyboard warrior.
Yes I see, you're cherrypicking again.
Fuck off.
In fact, someone on the Phoronix forums posted a bunch of links to Joey's debian-devel posts which seems to bear this out.
Especially the first one is a clanger. If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.
And no, that first post is not directly related to the Debian Constitution. That the idiotic GR trying to override the Technical Committee decision two weeks before the Jessie freeze is inspired by this kind of drivel, and that the Constitution makes these kind of purely political overrides of the technical decisions possible is rather evident though.
Really, if you are going to post your ideology-blinkered screeds, do your research first. This makes you look ridiculous.
You don't have to write a very complex daemon to do that. Just write a dbus listener that subscribes to service start events on the system bus. I could do something like that in about 2 hours with a few lines of Perl.
In fact, on a discussion list for 'Linux Experts' I provided one such script in 30 minutes when someone asked for a way to react to new devices being added to the system.
Dude, someone posted a list of possible verification mechanisms straight from the systemd documentation, and you called them guesses. Go get some treatment for your projection issues, ok?
Perhaps that is because you are so wedded to your biases that you are not reading the answers provided. As I said, irrational.
Someone else posted the full list of systemd verification mechanisms in this subthread. I'm going to refer you to that.
And in cases where there is no mechanism in place, for example when systemd is executing an rc script, I have the exact same mechanisms you describe: roll them myself by scripting.
I fail to see the problem here, the systemd way is a superset of the rc way. If you think that is worse, then I stand by my 'irrational' comment.
I assume you wanted to answer my parent, as you are just agreeing with me here.
I have the exact same setup, and I experienced the reverse: using sysv init rpcbind would deadlock with networking, because networking tried to start nfs. Switching to systemd solved that problem.
So we have two competing anecdotes. Now what?
Behind every great computer sits a skinny little geek.