3 ms·

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 ini

by 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

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.