3 ms·

I'm not sure what rose tinted glasses you're wearing but this is certainly a take. Experience, maintaining 1000s of concurrent servers, VMs, for dozens of comp

by b112 4y ago

I'm not sure what rose tinted glasses you're wearing but this is certainly a take. Experience, maintaining 1000s of concurrent servers, VMs, for dozens of companies, over 30 years, had shown me how systemd has been a negative, not a positive. Part of the issue, as I highlighted, is feature scope. In fact, I said nothing bad about core systemd, as an init system. As I said prior, as an init system, it would have been fine without all the added bloat. But here we have it handling everything under the sun, but again.. poorly. Which leads to another issue, change. An init system is about stability, and stability is absolutely more difficult with change. Systemd should shed everything not directly init related, and spend all efforts to stabilize, and keep pace with mainline, and kernel changes. That, and nothing else. In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me.

xyzzy_plugh 4y ago
> In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me. I'm not sure why you feel the need to attack my experience, but I maintained an internal Linux distribution for a Fortune 500 through the transition to systemd, managed fleets of 10-100k concurrent hosts, written hundreds of systemd units... You're simply fighting against the grain. As a systems administrator, systemd helps you get stuff done. It's very powerful, and almost every feature can be simply ignored if it's not for you, which is great. The problem is that so much is intrinsically coupled to init. Want to start per-user daemons at user log in? Manage logging uniformly without the pitfalls of traditional syslog? Define reliable service state targets across network state changes? Isolate subsystems? Zero-downtime deploys without writing complex application daemonization logic? Portable services? Snapshots? Peripherals? Not to mention all the incredible work to make multistage bootloaders (and single stage!) completely integrated. Straightforward to debug, patch, build yourself. It's definitely the worst, except for every alternative. I'm sorry that you find it so miserable. You linked to Ubuntu, so if that's the bulk of your experience, I encourage you to try a better managed distro. Debian, Arch, NixOS, or roll your own.
- b112 4y ago
  I'm not sure why you feel the need to attack my experience When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience. Obviously we won't agree here, we're too far apart, so I guess there is no point in discussing further. I likely won't be checking back.
  - xyzzy_plugh 4y ago
    > When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience. I've never mentioned apache2 so I don't know why you think I care about it at all -- I don't. I'm not sure what this has to do with my experience. Your gripe appears to be squarely with the maintainer responsible for packaging apache2 for your distribution, or distribution maintainers who are responsible for configuring systemd defaults. If you blame systemd for setting a default that maintainers ignore the consequences of, then I'm not sure what to tell you other than that you're barking up the wrong tree.

by b112 4y ago

xyzzy_plugh 4y ago

> In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me. I'm not sure why you feel the need to attack my experience, but I maintained an internal Linux distribution for a Fortune 500 through the transition to systemd, managed fleets of 10-100k concurrent hosts, written hundreds of systemd units... You're simply fighting against the grain. As a systems administrator, systemd helps you get stuff done. It's very powerful, and almost every feature can be simply ignored if it's not for you, which is great. The problem is that so much is intrinsically coupled to init. Want to start per-user daemons at user log in? Manage logging uniformly without the pitfalls of traditional syslog? Define reliable service state targets across network state changes? Isolate subsystems? Zero-downtime deploys without writing complex application daemonization logic? Portable services? Snapshots? Peripherals? Not to mention all the incredible work to make multistage bootloaders (and single stage!) completely integrated. Straightforward to debug, patch, build yourself. It's definitely the worst, except for every alternative. I'm sorry that you find it so miserable. You linked to Ubuntu, so if that's the bulk of your experience, I encourage you to try a better managed distro. Debian, Arch, NixOS, or roll your own.

b112 4y ago
I'm not sure why you feel the need to attack my experience When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience. Obviously we won't agree here, we're too far apart, so I guess there is no point in discussing further. I likely won't be checking back.
- xyzzy_plugh 4y ago
  > When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience. I've never mentioned apache2 so I don't know why you think I care about it at all -- I don't. I'm not sure what this has to do with my experience. Your gripe appears to be squarely with the maintainer responsible for packaging apache2 for your distribution, or distribution maintainers who are responsible for configuring systemd defaults. If you blame systemd for setting a default that maintainers ignore the consequences of, then I'm not sure what to tell you other than that you're barking up the wrong tree.