4 ms·

What does this article have to do with systemd, let alone the very specific, recently-widely-discussed issue you're referencing to? edit: Thanks for the downvo

What does this article have to do with systemd, let alone the very specific, recently-widely-discussed issue you're referencing to? edit: Thanks for the downvotes! I love that anything can be used as a non-sequitur to start bagging on systemd these days. Apparently it's wrong to even ask someone how this article about motd relates to systemd. I'll try to remember that.

qwertyuiop924 10y ago
It's another example of invalidating an old convention for no good reason. And the entirety of systemd is an overly complex mess that does a lot of this. It tries to replace cron. It tries to replace automounters. It tries to replace inetd. It will try to replace dbus, with the aid of the kernel. It replaces everything for no good reason, and that which it doesn't replace, it consumes. Do one thing well, work together, and handle text streams? More like do everything meh, work alone, and handle binary formats known only to you.
- serge2k 10y ago
  So this article has nothing to with systemd.
  - qwertyuiop924 10y ago
    ...Aside from the fact that the article is about the attitude amongst devs that manifested itself both as the motd-framework and as systemd, making this article thourougly linked to systemd, yes.
    - prodigal_erik 10y ago
      The problem is bad taste about how responsibility and customization should be divided between discrete components, and how the boundaries should be managed over time. systemd is merely another symptom.
      - qwertyuiop924 10y ago
        Which is what I said in my original post.
dredmorbius 10y ago
1. Take something with an established functionality, that works, at least to some order (I'm aware of the debates on this concerning systemd). 2. Replace it. Without apparent option. In the /etc/motd case, the problem was one of swapping a read file with a dynamic process in more-or-less the same namespace. Systemd at least advertises its malevolence. 3. Fail to adequately document behaviours. 4. Deprecate bug reports. 5. Create a fragile system within a core system context (login(1), init(8)). Rinse, wash, repeat, rofl, weep.
- qwertyuiop924 10y ago
  Yep. That about sums it up.
qwertyuiop924 10y ago
>edit: Thanks for the downvotes! I love that anything can be used as a non-sequitur to start bagging on systemd these days. Apparently it's wrong to even ask someone how this article about motd relates to systemd. I'll try to remember that. I agree you shouldn't have been downed, but I DID explain in detail, as did others, why my post wasn't a non-sequitur.

qwertyuiop924 10y ago

It's another example of invalidating an old convention for no good reason. And the entirety of systemd is an overly complex mess that does a lot of this. It tries to replace cron. It tries to replace automounters. It tries to replace inetd. It will try to replace dbus, with the aid of the kernel. It replaces everything for no good reason, and that which it doesn't replace, it consumes. Do one thing well, work together, and handle text streams? More like do everything meh, work alone, and handle binary formats known only to you.

serge2k 10y ago
So this article has nothing to with systemd.
- qwertyuiop924 10y ago
  ...Aside from the fact that the article is about the attitude amongst devs that manifested itself both as the motd-framework and as systemd, making this article thourougly linked to systemd, yes.
  - prodigal_erik 10y ago
    The problem is bad taste about how responsibility and customization should be divided between discrete components, and how the boundaries should be managed over time. systemd is merely another symptom.
    - qwertyuiop924 10y ago
      Which is what I said in my original post.

dredmorbius 10y ago

1. Take something with an established functionality, that works, at least to some order (I'm aware of the debates on this concerning systemd). 2. Replace it. Without apparent option. In the /etc/motd case, the problem was one of swapping a read file with a dynamic process in more-or-less the same namespace. Systemd at least advertises its malevolence. 3. Fail to adequately document behaviours. 4. Deprecate bug reports. 5. Create a fragile system within a core system context (login(1), init(8)). Rinse, wash, repeat, rofl, weep.

qwertyuiop924 10y ago
Yep. That about sums it up.

qwertyuiop924 10y ago

>edit: Thanks for the downvotes! I love that anything can be used as a non-sequitur to start bagging on systemd these days. Apparently it's wrong to even ask someone how this article about motd relates to systemd. I'll try to remember that. I agree you shouldn't have been downed, but I DID explain in detail, as did others, why my post wasn't a non-sequitur.