SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
hehe. If you think this is backward you should check out JCL condition code logic sometime.
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!
Originally Posted by GazL
If you think of the runlevel directory as a list of things to stop(if started), and things to start(if stopped), in order to achieve that runlevel then it doesn't seem quite so crazy. The idea just takes a little getting used to.
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.
But in our enthusiasm, we could not resist a radical overhaul of the
system, in which all of its major weaknesses have been exposed,
analyzed, and replaced with new weaknesses.
-- Bruce Leverett, "Register Allocation in Optimizing Compilers
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
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.
Last edited by astrogeek; 06-08-2013 at 05:42 PM.
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.