[davidstrauss]

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).

[falcolas]

> 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

> 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]

> 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]

>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]

> 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.

[c_rrodriguez]

Init has no idea of the screen brightness.. that 's just another thing the author pull out from his back-passage. a separate service systemd-backlight@.service(8) saves and restores the backlight state, because firmware does not remember it or if it does, it is buggy.

[digi_owl]

I think you will find that the brightness stuff is aimed at Wayland, not X11. The latter is something that many wants to see depreciated ASAP.