I personally don't think that systemd and subverting unix philosophy is worth the trade of faster reboot times on my servers. It solves a "problem" that I don't have with a middleware solution that I don't want.
I have a eight-core CPU. Do I want to wait 80 seconds waiting for my laptop to boot because it is using only one core of CPU? Or do I want to wait 20 seconds waiting for my laptop to boot using all the cores available? I do not know what your use-case is, but to me, the choice seems pretty obvious. Can you provide any reason why it is a "perceived" issue, not a real issue?
EDIT: 80 seconds or 20 seconds are not the hard numbers, these are just used to show 4x speed-up on 8-core CPU. Also, why the downvote? Is HN becoming another echo chamber where people can not accept different opinion without downvoting?
> if using Linux as a desktop OS, aren't pestered by the extra handful of seconds.
Your last point seems argument for the sake of argument. We are in a technical discussion, not a religious discussion. I did not buy a 8-core CPU to wait extra seconds paying electricity bill for the unused CPUs to validate someones hatred for some specific init system. If systemd can better utilize my system resource and cut my waiting time, I am going to use that. My lost time is the real issue, someones irrational hatred for something bears no value to me.
Init-time amortized over uptime. 5 seconds to boot is a big deal for a box that comes up, lives for 60 seconds, then dies. Not so much for a box that comes up in 5 seconds and stays on for 2 years.
> Your last point seems argument for the sake of argument. We are in a technical discussion, not a religious discussion.
And yet, you're making up numbers to paint a picture you want others to see. You suggest that I'm arguing from opinion when you're making up details because you want to be seen as correct.
> If systemd can better utilize my system resource and cut my waiting time, I am going to use that. My lost time is the real issue, someones irrational hatred for something bears no value to me.
Then use systemd. Or don't. This is what I meant about "perceived." You perceive init's boot time to be your/an issue. I haven't had such a problem.
---
You're coming off as dramatic and aggressively-emotional, which is my cue to walk away from our exchange.
Parallelized init sequences have benefits, but I suspect this exaggerated '80 second' boot time, and the related '20 second' ideal, stems from either a misconfiguration, complete hogwash, or very particular worst-case setup (assuming an 8 core laptop has an SSD, and assuming a very conservative 200MB/s random-read speed, 80 seconds is enough time to populate 16GB of RAM from disk).
Of course. But an init system should not be optimised for often reboots, since it's a marginal and unlikely scenario.
Starting up is a subset of rebooting, which is fine to spend time optimizing for, even though the Linux architecture lends itself towards long uptimes (well, until the complexity of systemd gets into the mix ;)).
And for reference I have compared sequential vs. parallel on rotating disks and SSD for myself. And there was almost no difference in boot time between both (only significant speedup was from replacing the rotating disk by the SSD).
systemd myth #2: systemd is about speed
I'm aware of their propaganda.
You said:
> it's working on "perceived" issues with Linux, e.g. plaintext logs being too large or sequential boot processing being too slow.
So you are claiming that the point of systemd is faster boot times.
I attempt to point out that this is false. As the myths page states:
> Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. [...] reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
This comes up a lot because one of the most visible changes when distributions first switched to systemd was how fast it booted, which led to a lot of people talking about how fast systemd was.. which leads to a lot of people thinking that the speed was the whole point...
The usual response to this from people such as yourself is "who cares, boot times are irrelevant for servers anyway" which is why the next myth points out a couple of reasons why you might care about boot times on a server anyway.
>So you are claiming that the point of systemd is faster boot times.
I was stating that was one of their intentions, which I'm still not convinced wasn't one of their goals (that same blog even suggests that is one of the major advantages (reasons for existence?) http://0pointer.de/blog/projects/systemd.html).
If it's not a symptom of NIH or wanting speed-ups for init, I really don't understand its purpose. If they (systemd/redhat crew) wanted to write a better babysitter, write a faster "better" ("invented there") supervisord. If they want faster startup times, patch init to support N-routes and some hot-path shell scripts with C-based alternatives.
Disclaimer: I do see systemd as an overly complex, desktop-focused (e.g. if it works for GNOME and benefits laptop-users, out it goes), bloated, opaque (binary logs, pretending switches on a binary == having a toolchain) piece of RedHat-funded feature-creep that will be inferior, less stable than any init solution that follows a Unix philosophy. And one that, due to RedHat keeping a number of important players on the payroll, will end up boxing out decisions that would prevent it from being an underlying dependency.
Maybe I don't get it, but I really think I see it for what it is. I know I'm talking a lot of garbage, but I'm quite serious: if I'm foaming at the mouth like I just saw lizard people setting global policy in a secret meeting, please drop some knowledge on me.