3 ms·

I'm not sure what rose tinted glasses you're wearing but this is certainly a take. systemd sure does a lot, but it does it drastically better than how it was d

I'm not sure what rose tinted glasses you're wearing but this is certainly a take. systemd sure does a lot, but it does it drastically better than how it was done historically. It's been over a decade, this vitriol feels misdirected at this point. I cannot imagine going back to the cesspool of sysv rc-style init. What a headache. > This default is almost always the last way you want an init system to do. It should never be the default. What do you propose is a better default? If there is one, then distro maintainers are free to select it. I think the default chosen is very reasonable. > And now it thinks it should add another OOM killer, before the kernel! Talk about feature bloat! There absolutely should be another OOM killer. This strikes me as pure ignorance of dealing with OOM situations with any sort of intelligence. The problem you highlight lands squarely with the Ubuntu maintainers not configuring their desktop environment properly. They should be configuring the user session slice with looser memory pressure constraints, but generally handling OOM further down the stack is a very, very good thing. A proper desktop environment might take advantage of these controls to suspend resource-hungry applications not in the foreground. This also opens up the door to things like asking browsers to dump cache when they create memory pressure, and generally playing nicer with other applications.

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.

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.