[systemd-devel] self domuneting and customizable

[Lennart Poettering]

On Fri, 02.12.11 19:10, Wouter De Borger (w.deborger at gmail.com) wrote:

> Hi all,
> 
> I'm just learning to know systemd and it seems very nice, but I have
> one question/consideration.
> 
> System V init scripts are self documenting and customizable: they are
> scripts. It is easy to read and edit them. One can read through the
> init process from step one and learn to know every step of the process
> and tweak when required.
> 
> While systemd is much more powerful, the native parts are not easy to
> understand or adapt. They are more like magic. When reading the
> scripts, they aren't there. When they fail (let's say due to a non
> standard implementation of the mount command) they can't be patched
> on-the-fly.
> 
> What do the developers think of the trade-off between speed (native)
> and robustness/customisability/self documentation (scripted).

I am not sure I agree with the existance of such a dychotomy. systemd
does not expose a Turing complete language to script boot-up and is
fully declarative, but the ordering and behaviour can still be
determined via the dependency system which even can be queried during
runtime. I don't think that systemd is really that much more opaque than
shell. It's primarily different, but not more opaque. It might be a bit
more complex to grasp at first, due to the parallelized execution, while
shell based boot-ups are much more serialized. 

I very much disagree with your rubustness point, as shell scripts tend
to be quite fragile and error handling is chaotic and badly
defined. Finally, for a non unix guru shell scripts are harly
understandable, while systemd's unit files are short and relatively easy
to understand with a powerful set of options.

> More explanation:
> 
> 1- personal experience: when starting to work with openwrt, init
> scripts didn't work properly, to debug the issue, I read through the
> init procedure and placed some echo statements in the init scripts,
> until I found the bug. With systemd this would not work.

Well, systemd has proper debug tools and I don't think "echo" really
qualifies as one. So again, I'd claim that things are different, but not
any worse than on Sysv. In fact, I believe the debugging tools in
systemd are much superior to sysv.

> 2- I'm a software engineering PhD student. From this perspective I
> like the parrallellisation, lazy loading and event support very much.
> At the other hand, I also strongly believe in language oriented
> programming. If even gnome introduces a scripting language to make the
> shell more customizable, I find it surprising that the init system
> moves scripting languages out. I can see that speed is an issue here,
> but I wonder how you balance that against ease of use? Would it not be
> better to make the scripts faster? (Replace the shells by a
> interpreted language?)

Actually, we want to deemphasize scripting languages in the boot
process, to simplify things and make them easier to
understand. Declaritive languages like our simple unit files are trivial
to read, write and understand, much in contrast to shell scripts. We
generally try to provide simple, high-level controls that hide
complexity as well as we can. For example, we provide PrivateTmp=yes as
an option to set up a private /tmp for a service, something which is
incredibly complex to do in shell, but very easy with this switch.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.