On Fri, 02.12.11 19:10, Wouter De Borger ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
