I dont think input validation is any less of an issue with a binary. You could argue that at least with a script everybody can see if its doing something stupid.

I have used it. I have also used several systems like it on various Unix systems as the concepts behind systemd are not new. I have adapted to more changes in Unix/Linux and learned more new technologies that you can shake a stick at over the years and continue to do so.

My experience with systemd like initialisation systems is that they are not so easy for the new, fledgling administrators to understand and therefore are a source of application down time. I dont like them as a result. Is that OK with you?

Maybe you could learn a few things from people that have seen the same mistakes you make a hundred times before.

Firstly using a pid files is an utterly stupid idea and quite frankly, anybody who can not see that when they first think of them or read about them should not be an admin on any critical systems. However, much as I like init, init doesnt do pids more elegantly, it doesnt do them at all. The kernel does that by kindly telling init when one of its children has died and arranging for it to be able tell what the pid was.

init doesnt do much at all and thats why it works so well. It simply takes whatever run level you want, reads through /etc/inittab to see what jobs to start for that run level and starts them. It then re-starts them if it gets a child death signal and /etc/inittab said respawn. Simplicity itself even though most Unixes now break it by having it start one job that handles everything else. Im guessing the one problem with init is that it cant handle a process that forks and then exits and maybe thats the reason /etc/inittab is dying. Shame.

I also think the kernel handing orphaned processes over to init is cheating a bit but I like it :)

I have similar length and breadth of experience of Unix systems and to be fair, I have seen init break but only once and it was when I broke it myself. I forgot to put an & and the end of a "sleep 20000 /dev/tty10" while trying to keep a serial line to a printer working properly. Next re-boot hung the machine but I was able to guess what the problem was.

When I first saw SMF break I had absolutely no clue why I couldnt ssh into the machine nor where to start looking. It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.

For me, scanning through /etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix. Even this is sadly being slowly broken even before the utterly pointless systemd was born.

Me too.

Remember when we moved from a.out to elf executable format? That was a lot of work but we all could see the benefit and although software would break, everyone would know why.

I think I'm with you on this. Compared to Solaris, HPUX and even Aix, Linux has no place in an enterprise looking to keep costs down.

Good job nobody called or those seconds might have been forever lost.

Are using a UI for "date" as your argument?

Admittedly, setting the timezone is pain these days but thats because of the same thinking i.e make a simple thing as complex as possible.

Me too, but then I never left :)

But all these systems do exactly that too and its harder to find out why when they do.

I dont have three, I have four but Im very much with you on this.

Linux with systemd is finished for me at home and at work, well thats tough to change but I have started the debate.

One thing that made me thump my head against a wall with SMF was when a system booted but I couldnt ssh into it. sshd was not started because utmp was not "enabled" because mounting the filesystems failed because a single file system didnt mount. Ok, its fixable but sshd ran perfectly if started manually and it delayed getting production systems up by a few minutes. We get journalists knocking at the door if our systems are down.

I hate this stuff, none of my admins remember where the damn log files are because they play with it so rarely. A load of scripts run in sequence can easily be followed, however rusty you are.

Geography is not altered by your political affiliations.

Never heard of init?

Its good for me.

I might recommend Slackware in a professional environment as its the only Linux distribution I am aware of that is truly knowable and stable. However, it needs a good architect to design and develop the systems and procedures in order to keep it in tip top condition. If you have those resources then yes, I would recommend it. It wont break stuff.

With regards to Patricks Volkerdings conundrum, he has made good choices in the past and Slackware has the stated aim of being a real Unix :) However we will see I guess.

Who in their right minds ever relies on a PID file? I never have in nearly thirty years.