4 ms·

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 introdu

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?
    - c_rrodriguez 11y ago
      This is no different from crontab -e, visudo and other programs that invoke $EDITOR..
  - davidstrauss 11y ago
    > Why assume the user is too stupid or lazy to manually invoke vim and then systemctl daemon-reload? This is what it does: (1) Locates the current unit file, regardless of whether it shipped with a package or is already a custom one in /etc. (2) If there isn't one in /etc, it copies the current one into the correct place. (3) It opens $EDITOR on that file. (4) It runs systemd daemon-reload. It's really the first two steps that can be annoying because you'd otherwise have to run "systemctl status" to find where it is currently and then copy it over. I guess you could script that, but is it really so terrible to support that in systemctl -- which is just a normal user CLI utility, not anything with advanced privileges or critical impacts on system stability? Edit: Punctuation
falcolas 11y ago
> systemd was not introduced to decrease boot time Might wish to check your history a bit. From the horse's mouth: "Unfortunately, the traditional SysV init system was not particularly fast." In fact, if you read the entire blog post, the biggest gripe Pottering keeps repeating is how slow SysVInit is, and how to address that. http://0pointer.net/blog/projects/systemd.html http://0pointer.net/blog/projects/systemd.html > Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus. Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there.
- davidstrauss 11y ago
  > Might wish to check your history a bit. No matter how many complaints you may find about SysV boot time -- or even discussion about how to improve it -- it does not make systemd's primary purpose solving that problem. How many discussions does OpenStack's development team have about security? Is the primary purpose of OpenStack to provide security? > Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there. But that is not what the article said. It said, "Systemd made kdbus non-optional in its release." That implies that use of it is non-optional, which isn't the case at all. It is like saying Fedora has made Intel graphics non-optional because they ship support for it.

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?
  - c_rrodriguez 11y ago
    This is no different from crontab -e, visudo and other programs that invoke $EDITOR..
- davidstrauss 11y ago
  > Why assume the user is too stupid or lazy to manually invoke vim and then systemctl daemon-reload? This is what it does: (1) Locates the current unit file, regardless of whether it shipped with a package or is already a custom one in /etc. (2) If there isn't one in /etc, it copies the current one into the correct place. (3) It opens $EDITOR on that file. (4) It runs systemd daemon-reload. It's really the first two steps that can be annoying because you'd otherwise have to run "systemctl status" to find where it is currently and then copy it over. I guess you could script that, but is it really so terrible to support that in systemctl -- which is just a normal user CLI utility, not anything with advanced privileges or critical impacts on system stability? Edit: Punctuation

falcolas 11y ago

> systemd was not introduced to decrease boot time Might wish to check your history a bit. From the horse's mouth: "Unfortunately, the traditional SysV init system was not particularly fast." In fact, if you read the entire blog post, the biggest gripe Pottering keeps repeating is how slow SysVInit is, and how to address that. http://0pointer.net/blog/projects/systemd.html http://0pointer.net/blog/projects/systemd.html > Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus. Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there.

davidstrauss 11y ago
> Might wish to check your history a bit. No matter how many complaints you may find about SysV boot time -- or even discussion about how to improve it -- it does not make systemd's primary purpose solving that problem. How many discussions does OpenStack's development team have about security? Is the primary purpose of OpenStack to provide security? > Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there. But that is not what the article said. It said, "Systemd made kdbus non-optional in its release." That implies that use of it is non-optional, which isn't the case at all. It is like saying Fedora has made Intel graphics non-optional because they ship support for it.