summaryrefslogtreecommitdiff
path: root/doc/why.html
diff options
context:
space:
mode:
authorLaurent Bercot <ska-skaware@skarnet.org>2020-09-16 12:04:55 +0000
committerLaurent Bercot <ska-skaware@skarnet.org>2020-09-16 12:04:55 +0000
commitb0fe68c13b04af8c098d53ea999bba6b7395163d (patch)
tree298bab9f755edd10f4fd09c22beadb89f05f1be3 /doc/why.html
parent997b02adcc8384906339ea81ece5ba7244f3ef60 (diff)
downloads6-b0fe68c13b04af8c098d53ea999bba6b7395163d.tar.xz
Documentation fixes, by flexibeast
Diffstat (limited to 'doc/why.html')
-rw-r--r--doc/why.html20
1 files changed, 11 insertions, 9 deletions
diff --git a/doc/why.html b/doc/why.html
index 3ce1612..83647cb 100644
--- a/doc/why.html
+++ b/doc/why.html
@@ -26,14 +26,14 @@
<li> Good (?) old System V init, which can be made to supervise services if you perform <tt>/etc/inittab</tt> voodoo.
BSD init can also be used the same way with the <tt>/etc/ttys</tt> file, but for some reason, nobody among BSD
developers is using <tt>/etc/ttys</tt> to this purpose, so I won't consider BSD init here. </li>
- <li> <a href="http://cr.yp.to/daemontools.html">daemontools</a>, the pioneer </li>
- <li> <a href="http://untroubled.org/daemontools-encore/">daemontools-encore</a>, Bruce Guenter's upgrade to daemontools </li>
+ <li> <a href="https://cr.yp.to/daemontools.html">daemontools</a>, the pioneer </li>
+ <li> <a href="https://untroubled.org/daemontools-encore/">daemontools-encore</a>, Bruce Guenter's upgrade to daemontools </li>
<li> <a href="http://smarden.org/runit/">runit</a>, Gerrit Pape's suite, well-integrated with Debian </li>
<li> <a href="http://b0llix.net/perp/">perp</a>, Wayne Marshall's take on supervision </li>
<li> Integrated init systems providing a lot of features, process supervision being one of them.
-For instance, <a href="http://upstart.ubuntu.com/">Upstart</a>, MacOS X's
-<a href="http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/launchd.8.html">launchd</a>,
-and Fedora's <a href="http://freedesktop.org/wiki/Software/systemd">systemd</a>. </li>
+For instance, <a href="https://upstart.ubuntu.com/">Upstart</a>, MacOS X's
+<a href="https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/launchd.8.html">launchd</a>,
+and Fedora's <a href="https://freedesktop.org/wiki/Software/systemd">systemd</a>. </li>
</ul>
<p>
@@ -67,7 +67,7 @@ never wakes up unless it receives a command via s6-svscanctl. </li>
<li> System V init <em>is</em> process 1, so no problem here. </li>
<li> Integrated init systems, by definition, provide a process 1. </li>
<li> daemontools was not designed to take over init, although
-<a href="http://code.dogmap.org./svscan-1/">it can be made to work</a> with
+<a href="https://code.dogmap.org./svscan-1/">it can be made to work</a> with
enough hacking skills. Same thing with daemontools-encore. </li>
<li> runit provides an <em>init</em> functionality, but the mechanism is
separate from the supervision itself; the <tt>runit</tt> process, not the
@@ -102,7 +102,9 @@ process 1 against libdbus. This is insane.
Process 1 should be <em>absolutely stable</em>, it should be guaranteed
to never crash, so the whole of its source code should be under control. At
Upstart's level of complexity, those goals are outright impossible to achieve,
-so this approach is flawed by design. </li>
+so this approach is flawed by design. It is a shame, because the concepts
+and ideas behind Upstart are <em>good</em> and <em>sound</em>; it's the
+implementation choices that are its downfall. </li>
<li> launchd suffers from the same kind of problems. Example: Services
running under launchd must be configured
<a href="https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html">using
@@ -163,10 +165,10 @@ and instantly respond to commands they may receive. <tt>s6-supervise</tt> has
even been implemented as a full deterministic finite automaton, to ensure it
always does the right thing under any circumstance. Other supervision suites
do not achieve that for now. </li>
- <li> daemontools' <a href="http://cr.yp.to/daemontools/svscan.html">svscan</a>
+ <li> daemontools' <a href="https://cr.yp.to/daemontools/svscan.html">svscan</a>
maintains an open pipe between a daemon and its logger, so even if the daemon,
the logger, <em>and</em> both
-<a href="http://cr.yp.to/daemontools/supervise.html">supervise</a> processes
+<a href="https://cr.yp.to/daemontools/supervise.html">supervise</a> processes
die, the pipe is still the same so <em>no logs are lost, ever</em>, unless
svscan itself dies. </li>
<li> runit has only one supervisor, <a href="http://smarden.org/runit/runsv.8.html">runsv</a>,