&gt; (the documentation is very poor: &quot;dialog dyn-amically with a running fcron daemon&quot; didn&#x27;t really invite me to think that it had a job scheduling UI)<p>I... uh.... read the documentation -rather than the second headings- and immediately understood that it had a job scheduling UI. :) I understand that we&#x27;re all busy, but it does pay to take fifteen minutes or an hour every couple of weeks to sharpen the axe.<p>&gt; it&#x27;s not sufficiently built out that I will be able to trade my current toolset for it.<p>I never was claiming that you should. I was addressing your initial claim, mentioned a little bit later in this comment.<p>&gt; For example, it seems that it lacks any process isolation.<p>Linux does that.<p>&gt; Email-only reporting is not acceptable.<p>Consuming email is trivial. There are something like 349024823904 libraries and like a handful of good ones to do so in <i>every</i> popular language. :)<p>&gt; I agree that Fcron is a better Cron. But I also think that it&#x27;s a very poor Systemd.<p>Your initial assertion was that the only way to get a good cron was to implement systemd. I demonstrate that that&#x27;s not true, and you counter with &quot;Well, <i>that</i> cron&#x27;s not systemd!&quot;!<p><i>sigh</i>.<p>&gt; I&#x27;d much rather have a C program segfault on bad input right away...<p>You and I <i>both</i> know that it&#x27;s trivial to write a C program that does <i>exactly</i> the same thing that your hypothetical poorly-written bash program does. :) Bash didn&#x27;t invent Heisenbugs.<p>&gt;  It&#x27;s one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical sloppiness of Unix.<p>&#x2F;s&#x2F;Unix&#x2F;Bash or sh&#x2F; and I agree with your statement. I also note that Perl (<i>shudder</i>) is conspicuously absent from your list. :)<p>&gt; There&#x27;s much more to it than that, I believe. For example, preserving quoted arguments is a nightmare.<p>Thanks for the examples! I&#x27;ll go over them over the next couple of days and see what I can learn from them. :D<p>&gt; But I would bet that most developers don&#x27;t even know that bash has first-class array support. (If you know a better solution,<p>Did you accidentally a sentence or two? Also, the recurring theme that I&#x27;ve been spotting here has been &quot;Programmers who don&#x27;t know their language often write bad or broken programs in that language.&quot;. Is this <i>not</i> one of the larger themes of your statements? :)<p>&gt; Controlling SSH from scripts has always been painful and brittle for me.<p>Sorry, this is something that I&#x27;ve not yet had call to do. What exactly do you mean by &quot;controlling SSH from shell scripts&quot;? Something like<p><pre><code>   ssh user@host &quot;someRemoteCommand $AND_A_SCRIPT_VAR_TOO&quot;
</code></pre>
embedded in your script? (Or the equivalent here-document?)<p>&gt; As for &quot;entire OS built on shell scripts&quot;, every Unix distro out there is built on tons of shell scripts.<p>That hardly means that the entire OS is built on shell scripts. I argue that the vast majority of the shell scripts out there are to handle process startup. While this is <i>quite</i> important, it&#x27;s important to remember that the stuff that <i>actually</i> gets work done in the OS is <i>very</i> rarely written in Bash.<p>&gt; Erlang&#x27;s duck typing means it&#x27;s susceptible to sloppy inputs just like any other duck-typed language.<p>I see what you&#x27;re saying (and agree with your final sentence), but one could just as justifiably say<p>&quot;C and C++&#x27;s ability to permit the programmer to override the specified type of a given variable means that such programs are susceptible to errors of sloppy logic. We should <i>really</i> be using Haskell to write our system management programming.&quot; ;)<p>Anyway. Thanks for the ongoing conversation. This has been quite informative.