On a embedded system I have build using Debian Jessie, systemd is very verbose, more than sysvinit in my opinion. I wonder if the fact that systemd don't say so much in your case is not the result of a Fedora choice to make systemd less verbose by default.

https://wiki.debian.org/system...

The curious thing is that the systemd binary only read unit files and execute command accordingly. How can it bug because of a USB device?

I agree with you. Some project take time to get accepted and every bug is potentially a drama. This is nothing new, some venerable UNIX projects have also pass trough similar problems. We tend to forget this because there are now regarded as good old stable, but this was not always the case when there was published.

You can perfectly run Gnome applications on a KDE desktop as you can perfectly run KDE applications on a Gnome desktop. If you can prove the contrary, please report the problem.

And why did you complain on systemd not displaying something if the problem is completely unrelated to systemd (it could be a kernel/udev issue)? Now I agree that something is really wrong if you can't at least get a text login console, but again if it's a kernel hand, systemd can't magically bring something on the screen.

I don't say that it impossible that systemd is in fine the cause of your problem and that fix is needed to solve your case. But without more information is't both impossible to clearly prove that's a systemd bug, and impossible to create a fix if it's the case.

I never say to report directly to systemd project. Please report first to the Fedora community.

I don't know Fedora, but on Debian you can install sysvinit or upstart as a systemd alternative to help testing if the bug also show without systemd.

Did you understand that you compare a file manager based on a web browser to a login deamon???

Anyway systemd-logind uses the systemd API and Konqeror uses the KDE API (many of them actually) and Qt API. What's the problem? The dependency on the respective API is no more or less on the two example. Also, the two applications rely on D-bus and so indirectly depend on the services there expect to use on D-bus.

https://packages.debian.org/je...

The Gnome 3 windowing issues have nothing related to systemd architecture (and I personally prefer XFCE or MATE).

From what I remember from the time when dbus was created, the main issue at that time was that there was too many different messaging systems and, in addition to some technical issues, none was gaining enough consensus to normalize the situation. Both Gnome and KDE have experienced how difficult it was to change the messaging system only to found that there are each duplicating many works in a incompatible way.

The requirement to define a strict binary protocol was found to be the best way to normalize the situation. And this was a big success: since dbus is used by Gnome and KDE, all the low level services can publish an API that can be used by both projects. The initscripts didn't follow this trend and are now regarded as obsolete because there are unmanageable from dbus. I hope this show how normal is the central position of dbus into systemd.

The fact is that you want a machine that boot and automatically start some services. Yes you can manually call initscripts, but you need an other part to make you scripts called at boot time. This other part is either sysvinit+sysv-rc, or sysvinit+file-rc, or upstart, or systemd, or some others unusual ways. So I still keep my position that's the initscript that depend on sysv-rc or something other to be called at boot time. it's not an hazard if the Debian dependency graph has been corrected that way when upstart was packaged.

Calling a script at boot time with systemd is no a hack at all, and from the script point of view this will change nothing.

I don't understand how the konqueror example is related to systemd.

Ok, I understand you position.

Actually dbus is essentially a normalized binary protocol (http://dbus.freedesktop.org/doc/dbus-specification.html) and this was on purpose to allow differents implementations to cooperate. The communication part (the transport in dbus jargon) is not so strongly defined (there is multiple transports). How to send and receive a message could see some evolutions in the future (for example using kernel dedicated message passing instead of general sockets).

The idea is to not bound developers to a specific code to exchange dbus messages. From the view of the others applications, a specific application only have to comply to the binary protocol and to specify an API.

Nice to see that you make real analysis of systemd. I have read your progress.

I found curious your position about dbus. Since it's a central piece since so many years, it's logic that more and more services depend on it to publish an API.

Have you considered that your various reasons to disagree on systemd regarding UNIX philosophy could be useful to others peoples?

You try to link my small error on a 'ls' option to the QI of the systemd-proponents. If you think this is not unrelated I let you prove the relation to all the systemd-proponents. :-D

Contrary to you claim, I have nothing against peoples that prefer to use sysvinit over systemd. It there are happy with it, them there simply must take care of it themselves, because I am afraid for them that most of the maintainers of the leading distributions will probably not support system V init in the long term.

Now you can ignore systemd if you are just happy with system V init, or you can try to improve systemd if you think that you can propose a better architecture. But trying to keep everyone using system V init is not a acceptable position for too many peoples.

I know nothing about Powershell, but want I can say is that systemd uses declarative unit configuration files to get the information on how it must manage a service. Given how the systemd binary work, I fail to see how you can compare it to a shell.

Ok, you have see it and I did not notice. Happy ?

It just delicious how you can link completely unrelated things trying to prove your point. That certainly would explain a lot of your inability to show real facts about how systemd architecture should be improved.