4 ms·

Correction: it's working on "perceived" issues with Linux, e.g. plaintext logs being too large or sequential boot processing being too slow. I personally don't

by mjolk 10y ago

Correction: it's working on "perceived" issues with Linux, e.g. plaintext logs being too large or sequential boot processing being too slow. 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.

riyadparvez 10y ago
> 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).
justinsaccount 10y ago
http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html systemd myth #2: systemd is about speed
- mjolk 10y ago
  And yet, on that link, point #3 tries to sell fast boot-up times for servers. It's about the level of marketing-doublespeak I'd expect from a RedHat-backed initiative. I'm aware of their propaganda.
  - justinsaccount 10y ago
    Doublespeak? 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.
    - mjolk 10y ago
      I later thought about how I was making a logical fallacy in connecting the linked blog's assertions of "it's not about speed. speed matters for init on servers", apologies. The doublespeak quip was because the blog you linked-to sets arguments like "monolith? hardly! it's 69 individual binaries! complexity? oh, that's relative. systemd isn't compatible? systemd is plenty compatible as long as you do things our way." >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 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.

by mjolk 10y ago

riyadparvez 10y ago

> 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).

justinsaccount 10y ago

http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html systemd myth #2: systemd is about speed

mjolk 10y ago
And yet, on that link, point #3 tries to sell fast boot-up times for servers. It's about the level of marketing-doublespeak I'd expect from a RedHat-backed initiative. I'm aware of their propaganda.
- justinsaccount 10y ago
  Doublespeak? 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.
  - mjolk 10y ago
    I later thought about how I was making a logical fallacy in connecting the linked blog's assertions of "it's not about speed. speed matters for init on servers", apologies. The doublespeak quip was because the blog you linked-to sets arguments like "monolith? hardly! it's 69 individual binaries! complexity? oh, that's relative. systemd isn't compatible? systemd is plenty compatible as long as you do things our way." >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 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.