On 01/15/2015 07:05 PM, Steve Litt wrote:
> Hi all,
>
> I'm writing you because you're by far the most init aware people I
> know. I've created a web page about features and benefits of a few init
> systems. The audience for this web page isn't people like all of you,
> but instead for the average DIY Linux user, so it deliberately contains
> some oversimplifications.
>
> It's here:
> http://www.troubleshooters.com/linux/init/features_and_benefits.htm
>
> I'd appreciate if some of you could look this thing over and identify
> any factual errors. I'm not talking about oversimplifications, I'm
> talking about dead bang wrong info.
>
> As usual, I appreciate all that you are all doing!
>
> Thanks,
>
> SteveT
>
> Steve Litt * http://www.troubleshooters.com/
> Troubleshooting Training * Human Performance
>
These are my gripes, then:
What is your definition of "event-based"? As far as I'm aware,
the only system out of the lines you list that is truly event-based
is Upstart. systemd relies on targets and dependencies (thus
uselessd too), though udev being a part of it could, I suppose,
lend it such a classification. I contest OpenRC being event-based.
uselessd supports socket activation, as do nosh and to some
extent Upstart as well, with its upstart-socket-bridge(8).
perp having a D grade in documentation seems harsh and
unfounded.
systemd, uselessd and Upstart are capable of running
one-shot jobs.
uselessd is LGPL, much like systemd.
Your taxonomy of process dependencies is totally arbitrary and
nonsensical, seeing as ->
1) "Numeric dependencies" means there is no dependency system
at all, and that the administrator must manually calculate startup
ordering.
2) "Calculated dependencies" means there *is* a dependency
system, regardless of how it works. As such, this definition is
functionally useless.
3) "Script-based dependencies" aren't a formal dependency
system, so much as a way for an admin to enhance the
startup ordering of their services by polluting their
configuration data with executable logic.
systemd, uselessd and Upstart all make respawning optional,
yes.
You clearly have no idea as to the purpose of socket activation
if you think a "sleep 10" can offer the same benefits. Hint: Don't
think of it as "socket activation", but as ucspi-tcp or inetd.
Declarative syntax does not imply key-value pairs or INI syntax.
cgroups don't eliminate the need for double forking, because you
shouldn't be doing that in the first place under a supervisor.
Received on Fri Jan 16 2015 - 03:39:23 UTC