> X, or Wayland are not the same as an init service.
And that has nothing to do with what I was saying. I was talking about
programs being dependent on software which is not portable. The X library is
not any more portable than systemd: it only works with X. That's why you have
programs like XScavenger being entirely rewritten to use different libraries:
it's the only way to get these programs to work on non-X systems!
So, again, why is it the individual choices of programmers when it's X, but
"pushing it on the community" when it's systemd? Stop dodging the question.
> Again, you use the term "argument", who is arguing, this is a discussion,
and yes arguing in a discussion is not civil.
I don't know if English is your native tongue or not, so I'm not going to
fault you for not knowing what an argument is. But since you clearly don't
understand, here is the relevant dictionary definition from the
Merriam-Webster dictionary:
2 a : a reason given in proof or rebuttal
b : discourse intended to persuade
There is nothing "not civil" about argumentation. What do you expect us to
do, just agree with everything you say, even when what you say is patently
absurd and insulting?
> Would you accept it if SELinux were a hard dependency or requirement of
sysytemd for security purposes? Not saying this will happen, but would you be
ok if it was?
I really don't care. If the systemd developers find some SELinux facility to
be so useful that they prefer to make it a hard dependency like that, and
SELinux is libre software (which it is), it doesn't matter to me. The only
point where it could matter is if the use of SELinux caused some secondary
trouble for me, such as worse performance. But such a problem being caused by
a dependency is no different from the same problem being caused by simple
developer incompetence.
And, news flash, if SELinux did bother me so much, I would still be perfectly
capable of not using systemd, or modifying systemd to remove the dependency.
> Who determines the limit of what systemd can and cannot do?
Whoever contributes to it. It's not that complex.
If you don't like the direction systemd is taking, fork it. If a bunch of
people agree with you, they'll contribute to and/or use that version. If they
don't, you carry a minority viewpoint on how systemd should be, and the
simple fact is you have to deal with that.