4 ms·

Just out of curiosity, can you summarize where exactly it is wrong?

by czardoz 11y ago

exelius 11y ago
The tone is very negative and does not allow that there might actually be legitimate reasons for wanting systemd to do things that it does. It just reeks of fanboy drivel, not a well-reasoned analysis taking into account multiple viewpoints. This is the type of content I would expect on Reddit or Slashdot, but not HN.
witty_username 11y ago
See my comment. https://news.ycombinator.com/item?id=9982777 https://news.ycombinator.com/item?id=9982777
davidstrauss 11y ago
As a systemd committer, I certainly can. I don't have time for all of them, so I'll pull the first couple and a few other egregious ones. > Systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops. More on this small world hypothesis of the systemd devleopers below. systemd was not introduced to decrease boot time; it was introduced to properly manage dependencies and parallelism. Such an approach happens to massively improve boot times in many cases, but that's a side-effect. The delay introduced is specifically to account for the slow/unreliable initialization of certain docking station hardware that has no other known reliable method for detection. (This is what happens in Linux with certain reverse-engineered hardware.) Importantly, this delay doesn't impact boot time, only introduces a delay before allowing the system to sleep, so even the (made up) point about systemd being about boot times isn't affected here. > Screen brightness is something that should crash your boot up when it is not working. The TODO item is about avoiding restoration of screen brightness at boot to such a low level that some laptops consider it to be a "backlight off" state. Someone may have shut a laptop down (even automatically) with the backlight off, but we think it should probably turn back on on the next boot. Absolutely nothing to do with "crashing" bootup. > Systemd made kdbus non-optional in its release. Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus. > This one is a setback. Why is there no default editor in systemd in case of factory reset? I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique? In general, the piece shows disingenuous portrayal of actual issues to the level of clickbait and fails to understand that not everything in systemd's git repository runs as part of PID 1 (like the network management tools, for example, are a totally separate and optional daemon).
- na85 11y ago
  >The TODO item is about avoiding restoration of screen brightness at boot to such a low level that some laptops consider it to be a "backlight off" state. Someone may have shut a laptop down (even automatically) with the backlight off, but we think it should probably turn back on on the next boot. Absolutely nothing to do with "crashing" bootup. Honest question: Why does an init system need to know anything about screen brightness in the first place? Shouldn't X11 handle screen brightness? >I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique? This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor?
  - davidstrauss 11y ago
    > Honest question: Why does an init system need to know anything about screen brightness in the first place? Shouldn't X11 handle screen brightness? I think that's a reasonable question. I am only a regular desktop user of systemd for anything with a display, so I don't have a strong opinion there. All of my advanced systemd work is on server systems; I have more opinions there. > This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor? There isn't a built-in systemd editor; that's how disingenuous this piece is. Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is configured to be. Totally normal Unix behavior here.
    - na85 11y ago
      >There isn't a built-in systemd editor; that's how disingenuous this piece is. Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is configured to be. Totally normal Unix behavior here. Well, okay, but the suckless people are about simplicity. Adding systemctl edit seems like a completely unnecessary alias. Another feature for the sake of having another feature. Why assume the user is too stupid or lazy to manually invoke vim and then systemctl daemon-reload?

Just out of curiosity, can you summarize where exactly it is wrong?

by czardoz 11y ago

Just out of curiosity, can you summarize where exactly it is wrong?

The tone is very negative and does not allow that there might actually be legitimate reasons for wanting systemd to do things that it does. It just reeks of fanboy drivel, not a well-reasoned analysis taking into account multiple viewpoints. This is the type of content I would expect on Reddit or Slashdot, but not HN.

witty_username 11y ago

See my comment. https://news.ycombinator.com/item?id=9982777 https://news.ycombinator.com/item?id=9982777

davidstrauss 11y ago

As a systemd committer, I certainly can. I don't have time for all of them, so I'll pull the first couple and a few other egregious ones. > Systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops. More on this small world hypothesis of the systemd devleopers below. systemd was not introduced to decrease boot time; it was introduced to properly manage dependencies and parallelism. Such an approach happens to massively improve boot times in many cases, but that's a side-effect. The delay introduced is specifically to account for the slow/unreliable initialization of certain docking station hardware that has no other known reliable method for detection. (This is what happens in Linux with certain reverse-engineered hardware.) Importantly, this delay doesn't impact boot time, only introduces a delay before allowing the system to sleep, so even the (made up) point about systemd being about boot times isn't affected here. > Screen brightness is something that should crash your boot up when it is not working. The TODO item is about avoiding restoration of screen brightness at boot to such a low level that some laptops consider it to be a "backlight off" state. Someone may have shut a laptop down (even automatically) with the backlight off, but we think it should probably turn back on on the next boot. Absolutely nothing to do with "crashing" bootup. > Systemd made kdbus non-optional in its release. Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus. > This one is a setback. Why is there no default editor in systemd in case of factory reset? I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique? In general, the piece shows disingenuous portrayal of actual issues to the level of clickbait and fails to understand that not everything in systemd's git repository runs as part of PID 1 (like the network management tools, for example, are a totally separate and optional daemon).

na85 11y ago
>The TODO item is about avoiding restoration of screen brightness at boot to such a low level that some laptops consider it to be a "backlight off" state. Someone may have shut a laptop down (even automatically) with the backlight off, but we think it should probably turn back on on the next boot. Absolutely nothing to do with "crashing" bootup. Honest question: Why does an init system need to know anything about screen brightness in the first place? Shouldn't X11 handle screen brightness? >I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique? This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor?
- davidstrauss 11y ago
  > Honest question: Why does an init system need to know anything about screen brightness in the first place? Shouldn't X11 handle screen brightness? I think that's a reasonable question. I am only a regular desktop user of systemd for anything with a display, so I don't have a strong opinion there. All of my advanced systemd work is on server systems; I have more opinions there. > This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor? There isn't a built-in systemd editor; that's how disingenuous this piece is. Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is configured to be. Totally normal Unix behavior here.
  - na85 11y ago
    >There isn't a built-in systemd editor; that's how disingenuous this piece is. Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is configured to be. Totally normal Unix behavior here. Well, okay, but the suckless people are about simplicity. Adding systemctl edit seems like a completely unnecessary alias. Another feature for the sake of having another feature. Why assume the user is too stupid or lazy to manually invoke vim and then systemctl daemon-reload?