knowing the systemd unit options is not a reusable skill
That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Heh, i was wondering how long it would take before we would get something like this.
It was around before the Debian Technical Committee made its decision. It wasn't one of the options to choose from, but it was an existence proof, for those making the decisions, that systemd unit files will not lock them in and that there's a route for Debian packages that have systemd units on Debian kFreeBSD and Debian Hurd.
Too bad it is not the unit files one should worry about, but the continued scope creep of the systemd project.
by the time one want to move from systemd to nosh, or anything more limited in scope, one may have face the rebuilding of Linux user space from the ground up.
It's not the unit files as a potential lock-in that one need worry about now, because of the nosh project. But it most definitely was one thing that people thought about then.
the syntax is trivial and the options themselves are rather well documented.
Just as Real Programmers can write Fortran in any language, it is still possible to make horrendous messes even with systemd unit files of a mere 14 lines or so. http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented.
And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions.
(Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html )