Currently I do not understand the `s6-linux-init-shutdown(d)' way well, so the old-fashioned way is retained at least for now, given its simplicity in implementation and seemingly better flexibility. Frankly it is my intuition that the new way costs more than the old way, but does not provide that much in return. (Feel free to prove me wrong.)
It may cost more *to you*, but there is real and significant value in following existing interfaces that people are familiar with. Being able to just use "reboot" instead of the, uh, slightly less intuitive "s6-svscanctl -6 /run/service" to reboot your machine, is one fewer obstacle on the way to mainstream s6 adoption. Additionally, and maybe more to your liking, there are also technical benefits to never killing s6-svscan. Being able to assume that a supervision tree will be operational at all times, including during shutdown (and even in stage 4!), is really comfortable, it cuts down on a lot of specialcasing, it makes shutdown procedures recoverable, integration into various configurations easier (I'm thinking containers with or without a catch-all logger, for instance), and all-in-all has just less of a "screwdriver and duct tape" feel than a bunch of execline (or rc ;)) scripts. -- Laurent
