docs: mention that dinitctl enable defaults to boot as dependent.
[oweals/dinit.git] / doc / COMPARISON
index a8c023af97797f18709094c52f83986705daf769..6262a35ff5ae04e33dd0ba2c2c1a7009dbc9afc6 100644 (file)
@@ -1,18 +1,19 @@
 Comparison of Dinit with other supervision / init systems
 =========================================================
 
-This is intended to be an objective description of the differences between Dinit
-and several other similar software packages. I started writing this with the
-intention of justifying Dinit's existence, but don't know feel that this
-document achieves that goal. It does, however, serve as a short survey of
-service supervision and init systems.
+This is intended to be an objective description of the differences between
+Dinit and several other similar software packages. Due to a myriad of details,
+it is difficult to provide a very meaningful comparison without going into
+great detail (which this document does not). It does, however, serve as a
+short survey of service supervision and init systems, and provides a starting
+point for understanding the unique features of Dinit.
 
 
 Systems without dependency management
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
 A variety of init/supervision packages do not perform proper dependency management
-of supervisions. By this I mean that:
+of supervisions. By this I mean that, broadly speaking:
  - starting a service should automatically start any services that the former
    requires (and wait, if appropriate, until they have started)
  - likewise, stopping a service should automatically stop any dependent services.
@@ -31,58 +32,86 @@ packages do not:
 Cinit (http://www.nico.schottelius.org/software/cinit)
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 An obscure init system which apparently offers portability and dependency
-management, just as Dinit does.
+management, just as Dinit does. Development appears to have ceased some
+time ago, unfortunately.
 
 
 InitNG (http://initng.org/trac)
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 A highly modular init system which apparently offers dependency management
 (as Dinit does). Portability status is unclear; may be Linux-only (Dinit
-strives for portability).
+strives for portability). Development may have ceased (website is now showing
+Japanese text which I am unable to read) although there are what looks like
+maintenance commits in the Github repository at https://github.com/initng/initng.
 
 
 Nosh (http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html)
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Another seeminly modular init system offering dependency management and socket
+Another seemingly modular init system offering dependency management and socket
 activation, with BSD licensing. Service configuration is expressed through
 directory structure (symbolic links represent service dependencies, etc). It
-provides a simple shell-like scripting language with a fast interpreter, avoiding
-the need for standard shell scripts. It was originally designed for BSD systems but
-works on Linux too (i.e. is portable). It does not provide a D-Bus interface.
-Seemingly, this package addresses most of the various complaints that have been
-levelled against SystemD. Compared to Dinit, it favors chain-loading of smaller
-utilities to provide even more basic functionality. By comparison Dinit tends to
-avoid starting additional processes by design, expresses configuration in files
-and tracks state internally.
+provides a simple shell-like scripting language which can be used to describe
+how to start services (and to control resource limits etc).
+
+It was originally designed for BSD systems but works on Linux too (i.e. is
+portable). It does not provide a D-Bus interface. Seemingly, this package addresses
+most of the various complaints that have been levelled against SystemD. Compared to
+Dinit, it favors chain-loading of smaller utilities to provide even more basic
+functionality. By comparison Dinit tends to avoid starting additional processes by
+design, expresses configuration in files and tracks state internally.
+
+Nosh seems to be a quite mature system with a range of features that makes it
+appear competitive, feature-wise, with Systemd, though without a lot of the
+feature-creep extras that can easily be implemented separately.
 
 
 OpenRC (Gentoo)
 -=-=-=-=-=-=-=-
 The OpenRC system used in Gentoo Linux is a dependency-managing service supervision
-system with funcionality similar in some respects to Dinit. It provides parallel
-startup of services (like Dinit). Compared to Dinit:
- - OpenRC is configured using, and relies largely on, shell scripts
- - OpenRC cannot be used as a direct replacement for /sbin/init; instead it is
-   intended that OpenRC be started by init.
- - Although the build system seems to have some support for BSD OSes, it did not
-   build successfully on OpenBSD when tested (revision 33d3f33).
+system with functionality that may similar in some respects to Dinit. According to
+Wikipedia, it provides parallel startup of services (like Dinit).
+
+It is difficult to find high-level documentation regarding the operation of OpenRC.
+It seems that services must be specified via a shell script, and service
+configuration (eg to specify dependencies) is also specified as part of the script.
+
+Although the build system seems to have some support for BSD OSes, it did not
+build successfully on OpenBSD when tested (revision 33d3f33).
 
 
 S6-RC (http://skarnet.org/software/s6-rc/s6-rc.html)
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 S6-RC provides a dependency-management system over the top of the S6 supervision
 system. Apparently it maintains most state on disk. S6-RC requires compiling the
-complete set of service descriptions into a database. New services apparently
-cannot be added once the system is in operation.
+complete set of service descriptions into a database. New services cannot be added
+once the system is in operation, and service definitions cannot be changed in
+general, except by re-compiling the database; S6-RC will then start any new
+services as required (and stop any processes no longer considered part of an
+active service).
 
-S6 in general follows a philosophy of breaking up functionality into smaller
+S6 in general seems to follow the philosophy of breaking up functionality into smaller
 parts and implementing these smaller parts as separate programs, wherever
 practical. Thus, process supervision, log file management, and service management
 are all separate programs.
 
-In contrast, Dinit does not requires compiling service definitions, and allows
-new services to be added after the system starts. Also, Dinit houses a much larger
-body of functionality in a single executable program.
+In contrast, Dinit does not requires compiling service definitions, instead
+loading and parsing them on-the-fly. Also, Dinit incorporates service
+supervision and management into a single process. Some people may see
+the more modularised nature of S6/S6-RC as an advantage of that system; I
+personally feel that Dinit's one-process approach is not particularly
+problematic and that the various functionality it provides is closely enough
+related that splitting it into component processes would not be beneficial -
+However, I can understand the other viewpoint.
+
+S6-RC nicely manages chaining of service standard input/output, facilitating
+setting up a logging chain where a logging process consumes the output of a
+service, and either can be restarted while losing only minimal (if any)
+output from the logs.
+
+It appears that S6 supports only hard dependencies: that is if, a service depends
+on another then that service must start, and stay running. Dinit supports a number
+of dependency types including "soft" dependencies which allow the dependency to
+stop or fail without necessarily stopping the dependent.
 
 
 Systemd
@@ -90,14 +119,15 @@ Systemd
 Systemd is probably the most widely used init system on Linux as of the last year
 or two. Compared to Dinit:
  - Systemd provides a range of functionality not provided by Dinit, such as:
-   - setting UID, priority, and other attributes of the service process. Dinit does
-     not support this yet.
+   - setting priority and various other attributes of the service process that
+     Dinit does not support [yet].
    - seat/session management
    - syslogd replacement (or at least, partial replacement)
    - ability to run tasks at certain times
    - inetd replacement (lazily launch services to handle connection to IP ports)
    - asynchronous filesystem check/mount
    - control group (cgroup) / container management
+   - private tmp directories for services / login sessions
    - system time management
    Some of this functionality can be found in other daemons/packages which can be
    be used to supplement the functionality of Dinit.