Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets.
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification. Fact is, it doesn't matter the justification. You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore. Like I said earlier, it comes down to a matter of preference. If you don't need it for your use cases and/or you prefer initd, that's fine. Go ahead and keep using it. Those of us that like systemd and need it will continue using it.
So far the answer is software to make the core features of initd available to a wider audience because they aren't being used
No. What it comes down to is, I don't want to replicate systemd functionality by writing a bunch of shell scripts. I know it can be done. Apparently you enjoy doing that sort of thing. I don't. I want core functionality (ie: booting a system with a complex set of dependencies) to be readily available by writing/modifying a few configuration files, and that's it. Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl
You claim that, but you still don't seem to know the difference between systemd and journald.
Guys like you are professing that it is so good that anyone using initd must be fucking idiot
Actually, if you look up in the thread, you will see that I am, and have been, saying the exact opposite. If you want/like initd, by all means keep using it. I have no problem with that. But if you call me an idiot for liking/preferring systemd, that's what I take issue with.
You and all the other systemd experts are supposed to tell me why I *should* use it
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude. But I don't see how I'm twisting your words. You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all. And you assert that somehow the principal operation of journald is so inherently different from syslogd that you lose information, which is just wrong.
And there we have it. You yourself are now citing Red Had's dumb serialization of initd's functionality with a crappy set of runlevel shell scripts and your limited understanding of initd's functionality
Speaking of twisting words, that is not what I said. However you choose to do it, rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
Being forced into following fools who can't make an argument on technical grounds no matter how many times they are invited really sums up the reason why so many pro-initd people get frustrated.
And here you are, again, accusing me of being rude while in the same breadth calling me (and everyone else) a fool and/or idiot, but I digress...
The primary issue is that functionality people need is there, working out of the box, with systemd. They don't have to write or customize anything themselves in non-standardized ways that no vendors will agree upon. You say all of the functionality is there with inittab+initd. Fine, let's say I believe you. Why does no distribution ship it that way? Methinks the answer is, it is not as easy as you claim. Sure, you can hack some scripts together to approximate the same functionality, but it doesn't not work well enough or generally enough to be shipped by a distribution. And that is ultimately what people want.
Incidentally, can you explain why so many people have looked at this problem and concluded they can't do it with inittab+initd? Before Red Hat's systemd, there was Ubuntu's upstart, then OS X's launchd, then Solaris' SMF. Even FreeBSD is looking at moving away from init to something more like launchd. If you're going to claim that it's because everybody is an idiot, then that's a reasoning that is pretty hard to accept.