Josselin Mouette <j...@debian.org> writes: > Jonathan de Boyne Pollard wrote:
> You know, or at least should know, as well as I that one can > centralize the code to do all of those things, and abstract them > out of daemons into a service manager, without that service > manager being process #1. > I don’t know whether you are aware of how a UNIX system works, but you > might not have heard of how orphan processes are managed. Jonathan certainly does. :) > Said otherwise, it is not possible to write a reliable service manager > without integrating it to what happens in process #1. There are some nice reliability features that you cannot implement without making the service manager process 1. However, that doesn't change Jonathan's point, which is that people have been running process management frameworks for at least 15 years withouot making them process 1. I'm one of those people. It mostly works. I think systemd does a *better* job, but it's clearly *possible* to do process management without the help of process 1, and problems caused by that approach are relatively rare. There's really no need to oversell systemd's benefits here. It made a set of design decisions, which allows it to do some things better at the cost of other tradeoffs. There are lots of other systems out there that have made other design tradeoffs. None of these choices are "wrong" or "right"; they're just different points in a tradeoff space. The issue at the moment, at least from my perspective, is the extent to which we, as a project, want to require all people packaging software for the project to support multiple points in that tradeoff space as the price for incorporating their software in the distribution. One can be opposed to setting that restriction on software included in the archive while still acknowledging that there are multiple possible tradeoffs and some people may prefer different ones and may want to work on making it possible to choose them. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761f9ctk4....@hope.eyrie.org
