On Thu, Feb 06, 2014 at 12:34:49PM +0000, Simon McVittie wrote: > I'm sure we've been over this, on this very list, in several previous > threads. I used to think this was a great idea, too; I've been convinced > that it isn't feasible.
Yes, I concur with the reasoning that I didn't quote here. In fact I brought up many of those reasons on my own. I consider the eliding of dependency information the most difficult hurdle to overcome. > If you think you can prove me wrong, you're more than welcome to write > the tool that does this. I would predict that it will need to be written > in C/C++ to get enough control; it will either be Linux-specific or have > explicitly separate code paths for Linux and kFreeBSD; by the time it > works reliably, it'll look rather similar to systemd; and by the time > you've sorted out circular dependencies, it'll have about the same level > of coupling between components as systemd. If I'm wrong about that, > great; again, please prove me wrong. I think this is 90% correct. Writing a 100% compatible .service interpreter basically amounts to the same complexity as writing systemd. But there is a twist here. The stupid portability argument that many (including me) keep making over and over again. So rather than rewrite 100% of systemd to achieve 100% compatibility a feasible goal may(!) be to rewrite 10% of systemd in a portable way to be able to run 50% of the real world .service files. That's already a significant fraction in terms of not having to maintain init scripts. Unfortunately I will not be able to pull this alone. My earlier request for help or even interest was met with silence. I guess that most people are fine with running the reference implementation on a supported kernel. Me too. Now we drifted a fair bit from the original argument. Unlike systemd, upstart has a head start here. It provides a somewhat limited reverse(!) compatibility wrapper today. The design decisions made by the upstart developers make it easier to write and port this wrapper than it is for systemd for precisely the reasons not quoted from your mail. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206142054.ga16...@alf.mars
