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

[Steve Litt]

On Sat, 12 Sep 2015 07:42:48 -0400
Solomon Peachy <pizza at shaftnet.org> wrote:

> On Fri, Sep 11, 2015 at 11:11:13PM -0400, Steve Litt wrote:
> > If no architectural reason existed to shun systemd, the preceding
> > attitude would be more than enough.
> 
> The problem with this statement, is that in general, those 
> "architechural reasons" apply even more strongly to the 
> duct-tape-and-bailing-wire stuff that systemd replaces.

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

The word "sprawling" sticks out. I'd hardly call sysvinit "sprawling",
especially when compared to systemd. And inits like runit, Epoch and s6
are miniscule compared to systemd.

Here are some other snippets from this Wikipedia article:

  "Information is shared promiscuously among distant elements of the
  system, often to the point where nearly all the important information
  becomes global"

This is a description of systemd, not sysvinit or any of the smaller
inits. systemd is the one that shoots everything through dbus so
everyone knows (and needs to know) everyone else's business. Systemd is
the one that subsumes udev, libpam, and now comically su. By contrast,
sysvinit just acts as PID1 reaping zombies, and runs a process manager
that activates init scripts. Most of the rest of them are simpler and
more effective than sysvinit.

Another quote from the Wikipedia article:

  "Foote and Yoder do not universally condemn \"big ball of mud\"
  programming, pointing out that this pattern is most prevalent because
  it works, at least at the moment it is developed. However, such
  programs can become very difficult to maintain."

Focus on the sentence ending in "can become very difficult to maintain".

s6, runit, and Epoch, all of which can init a computer just fine, were
each created by one person and pretty much maintained by one person. If
one of those person stops maintenance it's no problem: People switch to
an alternative, or take over the code, which is code perfectly
understandable by one person. If one of these inits jumps the shark and
does something somebody doesn't like, that somebody can take over the
code and get it to work as desired.

Contrast those tight inits with systemd, which has required Redhat to
pay what, six programmer salaries since 2010 to get where it's gotten?
What happens if Redhat abandons it? Or more to the point, what do *you*
do if one day you stop liking where Redhat is taking your computer? How
do you back out of the systemd that's taken a million development
dollars to get where it's gotten?

I think by bringing up duct-tape-and-baling-wire, you've brought into
sharp focus exactly what's wrong with systemd architecturally.


SteveT

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