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

[Steve Litt]

On Sat, 12 Sep 2015 13:26:30 -0400
"Michael B. Trausch" <mike at trausch.us> wrote:

> 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?

If it weren't for the fact that the init scripts require a certain
comment, I'd describe it as a perfectly logical way to do things. The
other problem I have with sysvinit is the length and complexity of its
init 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.

Well, maybe. Until you provide the proper output on two systems
identical except for their init, I can't comment one way or another.

But it's a moot point. None of the inits is especially RAM expensive
for most use cases.

The operant question, which I asked and nobody has yet answered, is
"what do the systemd industry and systemd enthusiasts have against
choice?"

>  * 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.

I can see value of that in certain use cases. I don't need it, but
maybe some might. So we get the (to some) benefit of makefile-like
init, and pay the price of monolithic entanglement.

Some might see the value proposition, some might not. Which again
brings up the question, "what do the systemd industry and systemd
enthusiasts have against choice?"

>  * 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?

Linux has always had a rich set of tools for managing the system,
although possibly not "as a whole": whose role as a benefit could be
debated. Systemd has cemented its layer of rich tools over Linux's set
of rich tools, making the latter very difficult to use. Some folks
prefer tools that don't adjust the system "as a whole". What does the
systemd crew have against letting them to continue using those things
with systemd running?

>  * 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.

You're not the only one glad you don't have to order the crap yourself.
But what do you have against letting those who want to order things
themselves do so?

>  * 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.

There are different use cases in the world. That's why we have
different (and competing) software in the Free Software world. My use
case has no escaped daemons. Any daemontools-inspired process manager
holds on to those daemons for dear life.

Again, what does the systemd industry have against letting people
choose a different init system, without setting up stumbling blocks
throughout the system?

>  * 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.)

Udev existed long before systemd, and performed what you mention above.
Systemd co-opted udev and bound it tightly to the systemd monolith. Now
people are writing eudev and vdev so they can use udev without bringing
the whole systemd universe onto their computer.

>  * 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.

svstat /service/*

And if you insist on a summary on the first or second line, a tiny AWK
script can do that for you.

Use cases. Some of us can use AWK.


>  * Fact: systemd allows developers to push rich metadata to the
> journal, allowing system administrators to more clearly see "under
> the hood" for troubleshooting purposes. 

Which becomes quite necessary with systemd, because its "everything
depends on everything else" architecture eliminates the logical
junctions into which one can peer with diagnostic tests. The tools you
mention are like a check-engine light reader on a car: They give
certain codes, but if you get a situation not predictable by the codes,
you're in trouble.

> 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, 

Fine. That's all I ever asked. Construct systemd in such a way that you
can replace the parts of it you want to replace, and I'll shut up.


> but when there are so
> many objective reasons to not do so, it simply becomes stubbornness.

Fine. Stubbornness. Remove all the stumbling blocks, quit using Redhat
funding to make well working software require systemd, and I'll revel
in my stubbornness. But until you do that, I have to ask: What do you
have against choice?

And everybody, really, seriously, quit acting like sysvinit and Upstart
are the only alternatives. Everyone sees throught that.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust