On 10/22/2014 03:51 PM, Barry Shein wrote:
I wish I had a nickel for every time I started to implement something in bash/sh, used it a while, and quickly realized I needed something like perl and had to rewrite the whole thing.
Barry, you've been around a long time, and these words are pearls of wisdom. This seems to be the reasoning behind replacing the spaghetti known as 'initscripts' currently written in sh with something written in a real programming language. Upstart and systemd are both responses to the inflexible spaghetti now lurking in the initscript system, of which the pile steaming in /etc/init.d is but a part.
Sure, one can insist on charging forward in sh but at some point it becomes, as Ken Thompson so eloquently put it on another topic entirely, like kicking a dead whale down the beach.
This seems to be the attitude of the systemd developers, although they're not as eloquent as Thompson in saying it. But I remember being just as abrasive, just on a smaller scale, myself....... Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Wouldn't it be a case of 'do one thing well' if one could do away with executable shell code in each individual package that is going to run as root? Wouldn't it be more 'do one thing well' if you had a 'super' inetd setup that can start services in a better way than with individually packaged (by different packagers in most cases) shell scripts that are going to run as root? Shouldn't the initialization logic, which is 'one thing that needs doing' be in one container and not thousands? Now, I say that having been a packager for a largish RPM package several years ago. I waded the morass of the various packages' initscripts; each packager was responsible for their own script, and it was a big mess with initscripts doing potentially dangerous things (mine included; to clear it up, I maintained the PostgreSQL packages for the PostgreSQL upstream project from 1999 to 2004). Ever since 1999 there have been issues with distributed initialization logic (that runs as *root* no less) under hundreds of different packagers' control. It was and is a kludge of the kludgiest sort. Having a single executable program interpret a thousand config files written by a hundred packagers is orders of magnitude better, security-wise, than having thousands of executable (as *root*) scripts written by hundreds of different packagers, in my experienced opinion. If anything, having all initialization executable code in one monolithic package very closely monitored by several developers (and, well, for this purpose 'developers with attitudes' might not be the worst thing in the world) is more secure. It *is* a smaller attack surface than the feeping creaturism found in the typical /etc/init.d directory. And Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit and its cousin /etc/rc.local. Now, as much as I dislike this magnitude of change, it seems to me that systemd actually is more inline with the traditional Unix philosophy than the current initialization system is. But I always reserve the right to be wrong. And I am definitely not fond of the attitudes of the various systemd developers; systemd assuredly has its shortcomings. But it *is* here to stay, at least in RHEL-land, for at least the next ten years. Having said that, if you want to use Upstart, by all means use Upstart; RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered for quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6 rebuild (or actual RHEL6). And for those who bugle that systemd will be the 'end of unix as we know it' I just have one thing to trumpet: "Death of Internet Predicted. Film at Eleven."