Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Steve Langasek <vorlon@debian.org> writes:
> But as Andi said, there's no real conceptual difference between the two
> approaches, and I don't see anything here that weighs in favor of one
> project over the other. Do you agree?
No -- for me, this is a plus in the systemd column over upstart, and
likely will have an effect on my vote.
> Of course if you disagree, and feel this is a point that's relevant to
> the TC decision, I'd like to understand why.
I don't think the upstart synchronization approach has a future. It's
basically a hack to work around only the lack of synchronization, and all
it can deliver is a single bit of data. The problem is that there may be
more than a single bit of data that needs to be delivered. There may be
multiple synchronization points, there may be more information that the
daemon wants to tell its management process (the existing status reporting
interface is an example), and so on. But there's no way to extend
SIGSTOP. The systemd approach, while necessarily requiring a more complex
communications protocol, is clealy extensible for future needs as they
arise.
This is consistent with a pattern that I'm seeing when evaluating the core
init system functionality between systemd and upstart. upstart takes a
very conservative approach of only addressing known problems and doing so
in a fairly limited way. systemd takes a broader approach of trying to
understand the general problem and trying to create a way to write daemons
and other startup code that can be much simpler once systemd interfaces
are available.
There are pluses and minuses to those approaches, but given that both
projects are maintaining backward compatibility, and given that I find
myself generally nodding along with the systemd design decisions, I think
the systemd approach is more interesting and has more long-term upside
potential. upstart as it exists right now would solve a bunch of problems
for us, but not lay groundwork for solving more problems in the future.
systemd would both solve an equivalent set of problems and provide a path
forward towards making the overall system much more robust, and given the
breadth of the existing systemd deployment, it's likely that our upstreams
are going to start adding that support. It's a more appealing picture.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: