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

[Solomon Peachy]

On Sat, Sep 12, 2015 at 03:15:40PM -0400, Steve Litt wrote:
> >  * 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.

You have to compare apples to apples -- by the time you add up all the 
memory that the various shells and processes invoked by these init 
scripts, you'll find that systemd comes in considerably less.

(And yes, I've built distros and sets of init scripts from scratch, 
 having to carefully count the number of nested stuff.  I would have 
 [metaphorically] killed for something like systemd ten years ago..)

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

Oh, they have absolutely nothing against choice.  You're 
completely free to use a linux distribution that doesn't use 
systemd -- or build your own should you not find any options to your 
liking.

Or by "choice" are you really saying "my chosing to demand other people 
do things the way I want?"

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

If by "entanglement" you mean "a proveably-correct list of all 
dependencies and interdependencies computed at runtime", you are unique 
in that definition.

But you should also consider that traditional SysVInit "model" cannot be 
considered anything other than an "entanglement" of a whole lot of 
interdependent stuff smashed together until it mostly works.  Except 
when it doesn't.

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

You said it yourself -- "not as a whole", which means that "Linux" has 
always had a rich set of tools for managing different parts of a system.

> Systemd has cemented its layer of rich tools over Linux's set
> of rich tools, making the latter very difficult to use. 

Oh?  Please elaborate on which tools were made "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?

See my answer to above, except you should realize that the "systemd 
crew" didn't force anyone to do anything.  Instaead, your wrath should 
be directed at the multitude of Linux distributions who freely chose to 
adopt 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.

Incidentally, one of the outcomes of competition is that inferior 
options end up losing.

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

Please elaborate on what these new "roadblocks" are, and how systemd set 
them up.

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

You're entitled to your own opinions, but not your own facts.

udev operates completely independently from systemd, and any example to 
the contrary will be treated as a bug report and dealt with as such.

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

So how will this handle a stale pidfile left over from your system 
crashing hard, with another process using the pid?   How will this 
handle dangling child processes, preventing a new master from starting 
up?  (I could go on, but the failings are leigon)

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

So you're basically saying that you have to work around deficiencies in 
your chosen tools....

> Use cases. Some of us can use AWK.

Congratulations, do you want a cookie or something?  (Seriously, in this 
case that's like saying you know how to adjust the ignition points on 
your car.  That's all well and good, but there's a reason nobody builds 
new cars with points any more..)

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

Except (and I say this as someone who knows quite a bit about working on 
cars too) the code readers save a vast amount of time and effort, and at 
worst, you end up with the same situation you'd have without the code 
readers -- ie having to take everything apart and follow 
vehicle-specific diagnostic procedures.

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

Okay, what parts are you looking to replace?  Seriously.  What 
functionality would you be gaining, to balance against additional 
complexity?

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

Nothing, except when the word "choice" is used in a way that actually 
translates to "do work for me, for free"

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20150912/ce3ac1bf/attachment.sig>