The 25/07/12, Kevin Chadwick wrote: > > If a service is not provided: > > - with SysVinit you have to write the whole script usually relying on > > whatever library the distribution provides (which tend to be > > error-prone); > > - with systemd, you just write a configuration file. > > > > Well arch has some includes to make it prettier. Look: > On OpenBSD you have <...> > or <...> > or <...> I don't find that pretty nor even smart at all. > This also demonstrates how easy shell can be Or not. Come back to reality (and I won't talk about BSD systems which are not the Linux world), shell scripts for init are a nightmare for plenty of reasons: - various API; - API not always fully respected in all the scripts; - no real journal; - almost nothing in API for detailed logs; - bad experience with parallelism; - static dependencies; - not events aware (except for TCP sockets); - slower; - almost no cgroup isolation support (and so goes for resource limits strategies); - almost anything for IO class and priority; - nothing well-defined to wait for availability of resources (remote fs, advanced authentication protocols, etc); - tracking of jobs/daemons sucks; - respawing absent; - no D-BUS interface; - no possibility to select which daemons to start from kernel command line (so multi-environments configuration for laptops often sucks); - relying on large binaries (starting from the shells); - etc, etc. Nobody will convince me that the pretended easy, smart, robust, hacking-friendly, etc world of init scripts is a wonderfull world which just worked for ages. I've had too many glitches for years (often hard to resolve) ― sometimes indirectly related from so unexpected pieces of the system ― to believe such thing, sorry. The ini style for configuration files of systemd or the rc.conf split into 3 or 5 files looks to be nit-picking to me. > One of the founding principles of UNIX is that small tools that do > a single job well allow complete flexibility whereas large tools do > what the devs foresee very well but will likely hinder users or the > unforeseen uses (hacking). Hackers know C. Admins don't hack and write scripts, too often poorly; whatever my statement will hurt readers or not. -- Nicolas Sebrecht
