I support the activity codenamed „Devuan“ because I see it as an effort of keeping SystemD optional on Debian-based GNU/Linux installations.

First of all here are my critique points with SystemD:

• SystemD introduces dependecies on a specific init-system where there previously had been none.
  This violates the „Shell“ principle and is an architectural regression.
• SystemD attempts to incorporate too many functions, violating the principle of „Doing One Thing Right“.
  • For a prominent example, SystemD attempts to incorporate the essential service of system logging and replace it with a technically inferior solution, violating the principle of „Doing One Thing Right“, because that is one thing it does not do right. Allow me to remark that the discussion over adoption of SystemD should have ended at this point.
• SystemD has a background that is too much under the influence of a single business entity, RedHat Inc, making it prone to counterproductive manipulation and to becoming a violation of the principle of „Free Software“. Please note that this is not a critique of RedHat Inc. and whatever practises they apply (they are of course free to do whatever they come up with, as long as it is legal) but it is a critique of SystemD and of any activity of adopting it.

Second of all, I have the following critique points with the administration of the Debian project and several package maintainers:

• Administration: I disapprove the deliberation to make SystemD the default init-system for all of the reasons listed above.
• Maintainers: I disapprove the introduction of direct and indirect dependencies on component packages of SystemD into application packages.
  • I understand there exist dependencies on components of SELinux, but as opposed to SELinux, installing any component of SystemD makes running the SystemD service mandatory, and use of it then can only be circumvented by using the „systemd-shim“ package. „systemd-shim“ is not a solution but a workaround, perpetuating beforementioned technical regressions.
• Administration: I disapprove that a general resolution on this issue was prevented by means of tactical politics (calling off a clearly neccessary election for it could have rendered an unwanted result).
• Virtually everyone involved: I disapprove the status quo and situation of communication (or lack thereof) of now because it impedes efforts of resolving beforementioned regressions and circumventing beforementioned technical deficiencies. Specifically, suggesting that questioning beforementioned practises is „counter-productive“ actively demotivates package maintainers from resolving the technical regression of their packages depending on a specific init-system.

Since Devuan is in the process of manifesting itself, there is not as much to describe about what it is as can be described about what it should be. Allow me to formulate two project goals that I find highly favorable in the light of my previous critique points with SystemD and Debian:

• Dependencies on a specifc init system or its components must be removed from existing Debian packages.
• A clear signal must be sent to Debian project administration that the use of tactical politics to enforce substantial changes of design and implementation of Debian GNU/Linux will not be tolerated.

Finally, and I hope this is not misunderstood, I prefer activities helping those goals that come from within Debian over those that come from a Debian-derivate Devuan. And of course, I prefer any such activities that come from Upstream over those that take place inside Debian. But as for now, this is what happens while anything else is wishful thinking – or is it?