4 ms·

> sequential boot processing being too slow 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 co

> sequential boot processing being too slow 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?

mjolk 10y ago
It's a "perceived" issue because not everyone has written his/her init scripts in a way that cause a boot time of over a minute. Or have uptimes in the magnitude of years, or if using Linux as a desktop OS, aren't pestered by the extra handful of seconds.
- riyadparvez 10y ago
  As I have said 80 seconds or 20 seconds are not hard numbers, just used as an example. It can simply be rephrased as 4x speedup. I am not sure how the uptime argument is relevant here. > 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.
  - mjolk 10y ago
    > I am not sure how the uptime argument is relevant here. 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.
sklogic 10y ago
You should not reboot that often anyway.
- mjolk 10y ago
  Users should be free to reboot as often as they want. 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).
  - sklogic 10y ago
    > Users should be free to reboot as often as they want. Of course. But an init system should not be optimised for often reboots, since it's a marginal and unlikely scenario.
    - mjolk 10y ago
      I just realized that I used a truism in a way that could be read as scolding -- not my intention and I apologize for my communication if I offended. 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 ;)).
welterde 10y ago
That's assuming that booting is CPU-bound. However I am fairly confident that for over 90% of people it is IO-bound in which case throwing more CPUs at the problem won't make it go any faster (might even be slower). 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).

mjolk 10y ago

It's a "perceived" issue because not everyone has written his/her init scripts in a way that cause a boot time of over a minute. Or have uptimes in the magnitude of years, or if using Linux as a desktop OS, aren't pestered by the extra handful of seconds.

riyadparvez 10y ago
As I have said 80 seconds or 20 seconds are not hard numbers, just used as an example. It can simply be rephrased as 4x speedup. I am not sure how the uptime argument is relevant here. > 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.
- mjolk 10y ago
  > I am not sure how the uptime argument is relevant here. 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.

sklogic 10y ago

You should not reboot that often anyway.

mjolk 10y ago
Users should be free to reboot as often as they want. 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).
- sklogic 10y ago
  > Users should be free to reboot as often as they want. Of course. But an init system should not be optimised for often reboots, since it's a marginal and unlikely scenario.
  - mjolk 10y ago
    I just realized that I used a truism in a way that could be read as scolding -- not my intention and I apologize for my communication if I offended. 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 ;)).

welterde 10y ago

That's assuming that booting is CPU-bound. However I am fairly confident that for over 90% of people it is IO-bound in which case throwing more CPUs at the problem won't make it go any faster (might even be slower). 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).