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.
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.
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.
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.
I have no problem (serious enough) with systemd, you claim that systemd have problem regarding UNIX philosophy rules, and I still waiting the various reasons you have to think that way so.
I have read some parts of the systemd source code, and you? Why do you refuse to give any of your various reason why you disagree on the systemd architecture?
You did no explain anything at all about your reasons to disagree! Stop trying to escape the discussion. You have claimed that you have various reasons to disagree that Systemd is in line with the UNIX philosophy. I still waiting a list of your reasons.
It's simply because there choose to store the code of multiple applications in the same repository. There is already a lot of projects that do the same since a long time.
Then show to us what's we don't want to see, and explain what UNIX philosophy systemd breaks.
I don't give any credit to your conspiracy theory. Yes systemd is now a dominant component of the last distributions, like udev, dbus, xorg, NetowrkManager when there was introduced into the distributions at there time. This don't make them evil projects with the goal of controlling the ecosystem. An other example is git that have largely take over the others SCM in the open source community, do this make it an evil project that control an ecosystem? From the reactions I read, even get the feeling that it's just a few systemvinit fans that try to control the Linux evolution to keep them in the past forever.
Yes systemd is designed to make the maintainers work easier, your analysis is correct. Now what's broken for the users of systemd?
I don't comment on the RH support, as I only use Debian distribution or derived from Debian.
Without investigating the problem in detail, how can you be certain that systemd is the fundamental cause of your problem ? You hate it, ok, but this is not enough to make is the real cause of your problem, especially on Fedora that uses systemd since now, full 4 years. Searching on the internet, most of the USB mouse hang problem seem to be related to the kernel/udev management of the device suspend. Did you a least report the problem to the Fedora community?
I also pretend to have enough experience to very well know almost all this points. I am perfectly ready to listen at your explanations why the actual systemd architecture break any of this rules.
The systemd binary itself is essentially to replace the init scripts by service files.
The systemd-* binaries are applications that can replace some traditional applications by using libsystemd instead of using others librairies. There are all optional.
Among those systemd-* binaries there is a bunch of them specifically designed to provides minimal basic services on tiny diskless machines without/etc. There are completely optional and normally not activated on a normal distribution.
Try a Debian Jessie of a Ubuntu 15.04, you will see very few systemd-* binaries running: systemd-journald systemd-udevd systemd-logind That's all.
Agree that systemd did not make a server boot in a significant better way (I doubts that it degrade it either). But systemd on a server add some cool features to manage all the services in a standard way and to introspect into the details of how there run.
And "systemctl start foo bar" will start the 2 services foo and bar in a single command. There just require the related service files (instead of scripts) and systemd (instead of a shell).
Good luck to write a single init scripts that are directly usable on many distributions for a service that depend on multiples others services to run properly. Can you provides a like to one of them please?
Yes inittab can be configured to make sysvinit starting almost anything, I used this many time on embedded systems. I see two bigs problems with inittab:
1) From the maintainer point of view, it's not practicable to have any package adding or removing his rules directly into the file. The sysv-rc idea was a way to solve this problem.
2) There is no dependencies between services. This problem is still not well enough addressed in sysv-rc, but sysemd is specifically designed to take care of the dependencies between services.
I don't see the dependency on systemd so much a problem. Try to purge udev or dbus to see what happens for example.
I perfectly know how sysv-rc work, thanks, and this is the primary reason why I am more than happy to replace it with systemd. The runlevels and run order by the number in the filename of the script is terrible to maintain when there is dependencies between services.
I think that you wanted to wrote rc instead of rcS, because this last one only exists to call the former with an 'S' in argument (to start the single user runlevel):
cat/etc/init.d/rcS #!/bin/sh # # rcS # # Call all S??* scripts in/etc/rcS.d/ in numerical/alphabetical order #
I added the -Sr only because there display the size in a more pretty order. Such a big deal...
Now what's strange is that you complain about the -Sr options that have a real effect on the displayed order, but you superbly fail to notice that this is actually the -a option that do nothing in this case. So before pretending that you know everything better, show at least something coherent.
Yes I did. I will list them here so you only have to put your observations regarding systemd below each of them that apply:
Rule of Modularity: Write simple parts connected by clean interfaces. Rule of Clarity: Clarity is better than cleverness. Rule of Composition: Design programs to be connected with other programs. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. Rule of Simplicity: Design for simplicity; add complexity only where you must. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. Rule of Transparency: Design for visibility to make inspection and debugging easier. Rule of Robustness: Robustness is the child of transparency and simplicity. Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust. Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Silence: When a program has nothing surprising to say, it should say nothing. Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. Rule of Optimization: Prototype before polishing. Get it working before you optimize it. Rule of Diversity: Distrust all claims for one true way. Rule of Extensibility: Design for the future, because it will be here sooner than you think.
The point is that you compare a simple script with a systemd-* binary, complaining that you can't run any systemd-* binaries without the systemd infrastructure.
What you fails to understand is that the equivalent of init scripts in systemd is not the systemd-* binary but a unit configuration file. If you want to compare a systemd-* binary, take a binary that provide the same kind of service. What you will find is that the usual code (or libraries) in the traditional service application is replaced by a more standardized API in the systemd-* application. For example, instead of depending on libdaemon, the application will depend on libsystemd. See https://github.com/systemd/sys...
At the end systemd will reduce the number of dependencies required by the applications that use his API compared to an application that will try to provides the same features without the libsystemd API. From the architectural point of view this is a good move.
If you like the idea of having an other logind that the systemd-logind, just disable the systemd-logind service and wrote the service file to start the logind you like, or use the sysvinit compatibility to start it with a script.
The systemd infrastructure provides more features that the sysvinit. Gradually more and more code will use this interface. This is normal evolution. udev, or dbus stories was not so different.
Now what the point of trying to run systemd-logind withtou systemd infrastructure? If you need a logind without the systemd features, just use the old logind.
Slashdot Mirror
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.
I have no problem (serious enough) with systemd, you claim that systemd have problem regarding UNIX philosophy rules, and I still waiting the various reasons you have to think that way so.
I have read some parts of the systemd source code, and you? Why do you refuse to give any of your various reason why you disagree on the systemd architecture?
I have read this document more than ten years ago.
Now, please show the "various reasons" why you disagree.
Hint: http://interviews.slashdot.org... (read the answer about systemd).
You did no explain anything at all about your reasons to disagree! Stop trying to escape the discussion. You have claimed that you have various reasons to disagree that Systemd is in line with the UNIX philosophy. I still waiting a list of your reasons.
I should have to used 'login" instead of "logind", sorry.
systemd-logind can replace the traditional login, but it uses the systemd infrastructure to do his job, what's a surprise.
It's simply because there choose to store the code of multiple applications in the same repository. There is already a lot of projects that do the same since a long time.
Then show to us what's we don't want to see, and explain what UNIX philosophy systemd breaks.
I don't give any credit to your conspiracy theory. Yes systemd is now a dominant component of the last distributions, like udev, dbus, xorg, NetowrkManager when there was introduced into the distributions at there time. This don't make them evil projects with the goal of controlling the ecosystem. An other example is git that have largely take over the others SCM in the open source community, do this make it an evil project that control an ecosystem? From the reactions I read, even get the feeling that it's just a few systemvinit fans that try to control the Linux evolution to keep them in the past forever.
Yes systemd is designed to make the maintainers work easier, your analysis is correct. Now what's broken for the users of systemd?
I don't comment on the RH support, as I only use Debian distribution or derived from Debian.
Without investigating the problem in detail, how can you be certain that systemd is the fundamental cause of your problem ? You hate it, ok, but this is not enough to make is the real cause of your problem, especially on Fedora that uses systemd since now, full 4 years. Searching on the internet, most of the USB mouse hang problem seem to be related to the kernel/udev management of the device suspend. Did you a least report the problem to the Fedora community?
I also pretend to have enough experience to very well know almost all this points. I am perfectly ready to listen at your explanations why the actual systemd architecture break any of this rules.
So it's your turn now.
The systemd project have different parts:
The systemd binary itself is essentially to replace the init scripts by service files.
The systemd-* binaries are applications that can replace some traditional applications by using libsystemd instead of using others librairies. There are all optional.
Among those systemd-* binaries there is a bunch of them specifically designed to provides minimal basic services on tiny diskless machines without /etc. There are completely optional and normally not activated on a normal distribution.
Try a Debian Jessie of a Ubuntu 15.04, you will see very few systemd-* binaries running:
systemd-journald
systemd-udevd
systemd-logind
That's all.
Agree that systemd did not make a server boot in a significant better way (I doubts that it degrade it either). But systemd on a server add some cool features to manage all the services in a standard way and to introspect into the details of how there run.
Agree that journald need a bit more care, this is a known issue.
Tell us more what the real cause of your mouse problem, because from what you wrote, this is more likely to have something related to udev.
And "systemctl start foo bar" will start the 2 services foo and bar in a single command. There just require the related service files (instead of scripts) and systemd (instead of a shell).
Good luck to write a single init scripts that are directly usable on many distributions for a service that depend on multiples others services to run properly. Can you provides a like to one of them please?
Yes inittab can be configured to make sysvinit starting almost anything, I used this many time on embedded systems. I see two bigs problems with inittab:
1) From the maintainer point of view, it's not practicable to have any package adding or removing his rules directly into the file. The sysv-rc idea was a way to solve this problem.
2) There is no dependencies between services. This problem is still not well enough addressed in sysv-rc, but sysemd is specifically designed to take care of the dependencies between services.
I don't see the dependency on systemd so much a problem. Try to purge udev or dbus to see what happens for example.
I perfectly know how sysv-rc work, thanks, and this is the primary reason why I am more than happy to replace it with systemd. The runlevels and run order by the number in the filename of the script is terrible to maintain when there is dependencies between services.
I think that you wanted to wrote rc instead of rcS, because this last one only exists to call the former with an 'S' in argument (to start the single user runlevel):
cat /etc/init.d/rcS /bin/sh /etc/rcS.d/ in numerical/alphabetical order
#!
#
# rcS
#
# Call all S??* scripts in
#
exec /etc/init.d/rc S
I added the -Sr only because there display the size in a more pretty order.
Such a big deal...
Now what's strange is that you complain about the -Sr options that have a real effect on the displayed order, but you superbly fail to notice that this is actually the -a option that do nothing in this case. So before pretending that you know everything better, show at least something coherent.
Yes I did. I will list them here so you only have to put your observations regarding systemd below each of them that apply:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected with other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
The point is that you compare a simple script with a systemd-* binary, complaining that you can't run any systemd-* binaries without the systemd infrastructure.
What you fails to understand is that the equivalent of init scripts in systemd is not the systemd-* binary but a unit configuration file. If you want to compare a systemd-* binary, take a binary that provide the same kind of service. What you will find is that the usual code (or libraries) in the traditional service application is replaced by a more standardized API in the systemd-* application. For example, instead of depending on libdaemon, the application will depend on libsystemd. See https://github.com/systemd/sys...
At the end systemd will reduce the number of dependencies required by the applications that use his API compared to an application that will try to provides the same features without the libsystemd API. From the architectural point of view this is a good move.
What's the problem exactly ?
If you like the idea of having an other logind that the systemd-logind, just disable the systemd-logind service and wrote the service file to start the logind you like, or use the sysvinit compatibility to start it with a script.
The systemd infrastructure provides more features that the sysvinit. Gradually more and more code will use this interface. This is normal evolution. udev, or dbus stories was not so different.
Now what the point of trying to run systemd-logind withtou systemd infrastructure? If you need a logind without the systemd features, just use the old logind.