On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote: > Having a rock-stable PID 1 is nice and all, but it doesn???t help you if > something important crashes. On a production server, if apache crashes > and fails to reload properly because the scripts don???t get the ordering > right, it doesn???t help you that init is still running fine. It would > help you to have an init implementation that can detect which components > can be initialized and at what time.
The cases you describe still are pretty rare. Having used both implementations as PID 1, I was not able to make this noticeable. On the contrary I had more issued with running gpsd on systemd reliably. My conclusion from this? My data is a random outlier. For many users these benefits are so rare that they most likely don't care. > I was all for kfreebsd when it was proposed, but now that it exists and > nobody uses it, I am appalled at the idea of using it as an excuse to > stop making improvements to the linux ports. Should we stop any > migration to a decent networking system because BSD doesn???t support > netlink sockets, too? I was not meaning to imply that. On the contrary turning systemd into the default will/would require porting it to kfreebsd, dropping support for kfreebsd, or using different init systems for linux and kfreebsd. The latter implies a limited choice on init systems. This choice actually might make sense as the cost might be lower than porting systemd. So my bottom line here would be: Providing freedom of choice is neither something that is always good nor something that is always bad. It just happens to be useful sometimes. 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/20130513143146.gc28...@alf.mars
