Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
>
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
>
>> And here is the reply from Gentoo developer Patrick Lauer:
>
>> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
>
> This, sadly, was not particularly useful or interesting.
I disagree. His point isn't argued very well (seems more like a rant
than a discussion), but it's there.
> As near as I can
> tell, the core content was that he doesn't think cgroup management is
> particularly difficult (fine, but I don't think that was the point; the
> point, instead, was that it's important to have a single arbitrator, which
> if true poses specific technical challenges) and he believes that the
> components to systemd would be easy to implement as separate daemons if
> they were properly documented.
>
> I'm one of those people who thinks that nearly everything in Linux is
> horribly underdocumented, so I'm not going to argue with that point, but
> it's not a very useful statement from a practical viewpoint. systemd
> offers specific pieces of integrated functionality. By and large, no one
> seems to question that the operations enabled by that functionality are
> useful (although there is some debate over how useful). GNOME is not
> depending on systemd out of some nefarious plot. It's depending on
> systemd because GNOME wants to use those pieces of functionality systemd
> provides.
>
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality. Either
> there needs to be an argument that the functionality is not important and
> can be done without (which raises questions about how one would build
> GNOME in such an environment), or there needs to be some sort of plan for
> how equivalent functionality to systemd will be provided.
>From the above link:
"The only thing stopping me from reimplementing that functionality is
that I have no idea what it's supposed to *do* ... and I don't enjoy
reading through all of systemd to find out."
(about logind)
While I agree with your point, it's pretty difficult to reimplement the
"interesting" parts of systemd in other implementations of pid1 if
whoever wrote the "interesting" parts does not document it, does not say
what it's supposed to do, does not want to accept patches for things
they're not interested in, and is by and large uninterested in anyone
who prefers to use something else than whatever their kool-aid is.
I'll grant that maybe logind provides interesting functionality which
other projects might want to depend on, and that there's nothing wrong
with that. The problem, however, is that the functionality is not
defined: if I want to provide an alternative pid1 implementation, then
the specifications are clear, and I should Just Do It (not that I'm
going to muddle the waters even more by doing so, but you understand the
point). If I want to provide an alternative implementation of logind,
however, then the only spec out there is the logind code, which might
change one day to the next just because the logind developer feels like it.
This wouldn't be much of a problem if I could just take logind (and
udev, and dbus, and more things) out of the systemd source tree and use
it without systemd, should I want to. But you can't; the problem is that
the upstream of all these projects is by and large uninterested in doing
so, and also does not seem to support other people who are, and at least
the Debian maintainers of systemd have gone on record as saying that
they won't guarantee this would remain possible (if the systemd
developers would be willing to do so, then I suppose that could
ameliorate some concerns).
The "obvious" solution would be that the world changes to systemd
because what, essentially, amounts to a level of sabotage by the systemd
developers of things that aren't systemd. If systemd is in fact the best
choice "out there", of which I'm not convinced at this point in time,
then I wouldn't mind that (much). But I'd like us to do so for the right
technical reasons, not just because it means we make our lives easier in
not having to fight with a stubborn upstream all the time. We could,
after all, fork, like we have done on other occasions of stubborn upstreams.
Given all of the above, I would even argue that perhaps Debian should
*not* adopt systemd as init system, out of principle; if we were to do
so, then almost all the major distributions would be using systemd (with
the sole exception of Ubuntu; I expect redhat to switch to systemd for
their next EL version), which could go a long way to making it part of
what it means to be running "Linux". At that point, any competing
innovative implementations would simply face an almost insurmountable
heap of undocumented code.
Yes, absense of documentation is common on Unix and Linux systems; but
no, I do not think that this is okay, or that we should in any way
encourage that sort of thing.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Reply to: