[VLM]

The key is the expense vs reward ratio.

I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and tradition, which means copying a known good init script and editing nothing but the executable names is a great start, but its not really a serious problem. I don't care if its verbose, as long as its simple and understandable and most importantly, predictable.

Now instead of applying a language and tradition I know to a simple task like init, I get to learn a whole new ecosystem and technology to do about the same thing I always did except vastly more complicated, and I can't even shed the old knowledge because its needed elsewhere. That makes overall systems harder to use, slower, buggier, and less reliable. And thats defined as "progress" because its new so it must be better.

[chousuke]

Honestly, I don't think that argument holds much water.

Init systems are not "just shell". If you go and try to write a sysv init script with only shell skills, chances are your init script will be broken in some obscure way. Perhaps because you didn't specify LSB headers correctly, or your PID file handling is subtly broken, or you're missing a check somewhere and the script is racey. I can't really say how much reading it would take to catch all the corner cases with sysv init scripts, but for simple cases, you will be able to write a correct unit file after about 15 minutes of reading the manuals.

Knowing shell helps, but you'll still need the tool-specific knowledge.

[EmanueleAina]

I don't think it's really fair to compare writing unit files to being able to program in shell.

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 )

[JdeBP]

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...

[digi_owl]

Heh, i was wondering how long it would take before we would get something like this.

[JdeBP]

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.

[digi_owl]

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.

[JdeBP]

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.

[JdeBP]

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...