No thanks. I'm still trying to get my head around woman logic after 10 years marriage. The last thing I need is another challenge like that!
But what if the new runlevel doesn't have a 'kill' link for a service which doesn't need to be running in that level? E.g. What if you went from runlevel 4 to runlevel 1? Surely, runlevel 1 doesn't need a 'kill' link for every service on the machine?

From this angle, I'm happier with the Slackware way...

Either you don't know what that means, or you have failed to produce a strong argument and want to divert the conversation. Read ReaperX7's post and look at the part I quoted in my original post, then read my reply. That sentence is obviously about the requirement of knowing dependencies in SysV init and not about whether or not Slackware can run SysV-style init scripts. Your post was the straw man argument, not mine -- you replied to a point that I had not made. Additionally, I defended every angle of my point, both covering your assumption of its meaning and its intended meaning, and still showed my point's correctness (even from your misinterpretation). That is most certainly not a straw man argument. I will repeat myself here...and this of course hilights your straw man argument, not mine. "Anyway, this is all overblown, because good reading comprehension would have indicated that the focus of that sentence was on the requirement of knowing startup dependencies with SysV init, and that this is not unique with systemd." What I said was still absolutely correct (as shown by the "Slackware-style" adjective) even when you are making your straw man argument, and since that sentence was not meant to evoke discussion about Slackware's support for SysV init style scripts but was VERY CLEARLY about needing to know startup dependencies in both SysV init and systemd systems, it makes you look even more foolish.

If you wanted to intelligently argue against that point (which you absolutely have not done), you could say that, while you do, to a degree, need to know startup dependencies using SysV init systems (specifically in Slackware), the depth of knowledge required for adding third-party software is lower, because most third-party software is just run after the critical systems are already up (whereas in systemd you may have to explicitly specify which critical systems must be up). Thus, using systemd requires a *more thorough* knowledge of startup dependencies, while SysV init requires less (though non-zero) knowledge of those dependencies. I have successfully argued against my own point (though to a lesser degree than your all-nullifying straw man argument -- which was incorrect anyway).

Perhaps if you read my posts without some imagined snarky tone in your head you would see that they are actually factual. There are debatable points, and there are facts; you have chosen to debate facts. That is a fool's errand.

No, that's exactly how it's expected to work.
And don't call me Shirley!


I'm just glad slackware uses bsd-style init scripts instead and we don't have to worry about the sysv directories.

When I logged in this morning, the motd was:I'm not really opposed to systemd per se, but I'm confident that Slackware won't even consider including it unless the day comes when it has thoroughly proven itself.
Such are the benefits of living under a BDFL

Yes, and be thankful Patrick is in fact Benevolent. At least he listens to the concerns of the users.

"That's [Pat]. He fights for the Users."

Move over, "Bob", "Pat"'s in the house!

I was thinking TRON

Now all we need is a picture of Pat's head smoking a pipe.

True. I'm just saying that most discussions revolving around systemd that I've seen tend to be emotionally charged rather then technical.

Which implies that "technical" arguments are the only "valid" arguments in some sense, and that other arguments, emptional as they may seem, are not valid.

But our computers, being at the core of our knowledge, information, entertainment, interests and jobs, and liberties, are inherently more personal than many other technical subjects. So it is natural that these discussions include non-technical aspects. But to characterize every non-tecnical argument as being "emotionally charged" is really disingenuous.

And it really is ambiguous what a purely "technical" argument is anyway - can you defne that for us?

Similarly, that is in fact one very important reason that M$ vs Linux discussions usually become emotionally charged, and why the marketing interests always try to derail the very valid non-technical arguments onto the technical side track. Once there, a conclusion can never be arrived at simply because there is really no definitive technical right and wrong in many cases, so market speak can then previail.

For example, I myself reject any M$ product because they are harmful to my liberty, no "technical" argument can enter into that for me. But my valid non-technical arguments are summarily dismissed, so I am frequently characterized as "emotional" on the subject - so be it.

I see the same thing happening with systemd - the marketing interests want to have their way, regardless of any other valid, non-technical, so called, arguments by users.

For me, systemd binary logs alone are a deal breaker, they are inherently harmful to my computing uses. Having rejected them on that basis I am simply not interested in hearing so-called technical arguments about their superiority. But those who are convinced by those technical arguments then characterize me as emotional on the subject, but only because they similarly reject my own very valid, "non-technical" arguments.

Let's consider all arguments seriously and not try to reduce it to numerical analysis.

3 members found this post helpful.

Just to clarify what I said, when I say "emotionally charged", I'm referring to the outright anger commonly present in any systemd debate. I apologize for any confusion.

Computers are commodities and need to be sold like bread toasters and washing machines.

To be honest my washing machine's boot time is a bit too long, I might install systemd on it.

systemd is still in alpha phase.

as long as for example red hat is not using systemd for RHEL is not even considered stable.
and slackware will not consider using it before RHEL uses it. (look at the consider)

systemd still has a long way to go, lots of problems needs to be fixed, lots of features to be added.
just look at systemd's TODO list. http://cgit.freedesktop.org/systemd/systemd/tree/TODO

my personal guess is, that it will take 2 years before we can consider in implementing systemd.
systemd is aimed for desktops and not for servers.
for servers systemd is no improvements.
if you look at it from desktop side, than systemd can be a very good init system.

Homer's systemd: https://www.youtube.com/watch?v=4bHXMogzEm0