[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Michael B. Trausch]

On Sat, 2015-09-12 at 12:22 -0400, Steve Litt wrote:
> Trying to find a definition of "duct-tape-and-bailing-wire" in order
> to
> understand your assertion (by the way, it's spelled "baling"), the
> closest definition I could find was
> https://en.wikipedia.org/wiki/Big_ball_of_mud ;, which Wikipedia says
> is
> a "haphazardly structured, sprawling, sloppy,
> duct-tape-and-baling-wire, spaghetti-code jungle."
And just how would you describe an init system which as a fundamental
requirement for its own operation requires the invocation of a
serialized set of unstructured scripts?
I don't have time to take this to a full conclusion, as life is life,
but:
 * Fact: A pure barebones systemd-based system with all core services uses less RAM than sysvinit.
 * Fact: Systemd is the application of the Makefile algorithm to the boot up process.  Tell the thing WHAT needs done.  It determines the HOW. We've been doing this for years in our build trees, it makes perfect sense to apply it to system initialization and runtime maintenance.
 * Fact: Systemd provides rich tools for managing the "system", as a whole. It was never intended to be "just" an init.  It was intended to take the kludges that we've been applying year after year and consolidating them into the lightest possible implementations.  Why use ISC DHCPd when you have something that be in the idle process list and consume less memory?
 * Fact: Systemd is intended to allow system administrators to have the same power and flexibility in system management that some other operating systems have provided for a long time now. The Makefile-style algorithm eliminates a lot of ad-hoc ordering code that was previously necessary.  I get that you like the old way, but we've all been doing it the old way for years, and for my part: I'm *glad* I don't have to order crap myself. There's a reason that very few serious build systems use the shell-scripting approach vs. the Makefile approach. Humans are great at saying what needs done, while machines are much better at the ordering and dependency resolution aspects of it.
 * Fact: Systemd allows use of cgroups (inbuilt kernel functionality) to contain daemons. Standard init does not do so. Daemons can escape the control of standard init. They cannot escape the control of systemd.
 * Fact: udev provides a much more convenient method of handling things than standard scripting. If you need to load a userspace driver to handle a particular USB device (e.g., a generic HID sensor not handled by the kernel, or something similar), then you plug the rule in and systemd/udevd make it happen. (Of course, you do not need systemd for udevd, but since systemd and udevd play very well together, it'd be silly to not use it.)
 * Fact: systemd allows for rich reporting. "systemctl status" will tell you if all services are working or not, in the very second line of its output.
 * Fact: systemd allows developers to push rich metadata to the journal, allowing system administrators to more clearly see "under the hood" for troubleshooting purposes. Systemd allows developers to do the same for themselves, during the development process. What changes? The implementation of your process specific tools gets easier because you're no longer forced to deal with (potentially ambiguously) serialized data.
At the end of the day, it saves time and resources for those of us who
make our living managing systems.  For my part, I manage things ranging
from smaller than the Rπ to larger than a 1U. And systemd saves me time
and resources across the board.
Hold on to The Old Ways if you want, but when there are so many
objective reasons to not do so, it simply becomes stubbornness. We
humans like serialized, hand-managed things because we have a
sentimental attachment to micromanagement.  Thing is, computers do much
better when the micromanagement logic is all in the same place and is
purely consistent.  No longer do I have to worry about the
customizations made to the boot process or its ordering when I approach
a systemd system, because it will tell me with perfect consistency and
reproduction. And in this industry, perfect consistency and
reproduction saves time, saves money, and increases security.
Therefore, it's one of the few points in our field that matters with
very high significance over nearly everything else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150912/8ed653fc/attachment.html>