Steve Langasek <vor...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
