3 ms·

> I admit, I do not fully understand systemd ... > This indicates to me a very poor design. If not, it is a validation of the old UNIX saying "do one thing a

> I admit, I do not fully understand systemd ... > This indicates to me a very poor design. If not, it is a validation of the old UNIX saying "do one thing and do it well" and "keep programs small" (paraphrasing). You don't need to fully understand systemd to understand TFA describes a kernel fix. This isn't a systemd problem, systemd just makes use of cgroups. The kernel has a degenerate case handling lazy atime updates combined with cgroups.

pizlonator 1y ago
Kinda yeah? I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered
- pengaru 1y ago
  > I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered systemd is basically a victim here, you're quasi engaging in a tech form of victim blaming. don't blame systemd for making use of kernel features (cgroups) and without cgroups linux has no sandboxing capabilities, and would be largely irrelevant to today's workloads
  - pizlonator 1y ago
    If I was blaming only systemd then you’d be right. Look if I wrote a thing that caused kernel lockups then I’d blame myself even if the kernel dudes fixed the issue
    - lokar 1y ago
      The kernel has a very clear API and expected behavior. Systemd is not doing anything wrong, it’s using the API correctly. It’s a kernel bug.
TacticalCoder 1y ago
[dead]