[aklug] Re: systemd - was Re: multiple distros coordinate to establish /run directory

I am not trying to take sides, I am just trying to figure out what
systemd is. I need to know what it is before I can figure out where I
might stand on it.

Correct me if I am headed down the wrong path.

A "socket" is something akin to a socket in the wall that you connect to
similarly plugging an electrical cord into an electrical outlet, or an
ethernet cable into an rj59 outlet in the wall.

When I plug a standard extension cord or a lamp cord into what we
conventionally call an electrical outlet or an Ethernet cable into an
rj59 outlet, I normally expect to find 115v @ 60Hz or networking signals
(occasionally pots) from the respective sockets.

If I am following the general idea of systemd, something, not
necessarily within my control, can decide to change what is available at
the socket on the fly.

How do I connect to the socket confident that I am receiving expected
telemetry data from from Joe in ICU and that something hasn't
re-purposed the socket so that it's feeding data from the hospital's
HVAC system? I would prefer not to give Joe the "smoke test".

This is also the part of the concept that was making me uncomfortable.
It smells a lot like self modifying code. I was taught this was
something to be avoided. It was a long time ago that I was taught that,
maybe philosophies have changed over the years?

Jim G

On Wed, 2011-04-06 at 17:58 -0800, Arthur Corliss wrote:
> On Tue, 5 Apr 2011, barsalou wrote:
>
> > Nothing to disagree with here either. Maybe that is what the silence you are
> > getting is about....they all agree with you! :)
>
> :-) I seriously doubt it.
>
> > Some of the commentary isn't well thought out and many of the people make
> > conjecture and guesses that could be right on or completely off.
>
> I haven't read much commentary on the matter. I read an admission from the
> author about separate /usr disclaimers, looked at the web site and the
> source tarball, and came to my own conclusions.
>
> > I propose that instead of arguing, or trying to logic our way into a
> > particular position, we actually work to make it fail with simple specific
> > purposeful problems. It should be easy to do if it is 'overly complex and
> > buggy blob'.
> >
> > Something demonstrable (<-note the sorta play on words) is much more
> > effective than arguing one point or another with logic.
> >
> > The other thing that needs to be brought to light is that the entirety of
> > that conversation was many internet years ago.
> >
> > My main point was to ensure that I show proper appreciate to Jim for making
> > my life just a little easier by pointing me to what might be considered close
> > to the beginning of implementing systemd distribution wide.
> >
> > Who among you are willing to actively work toward breaking systemd to prove
> > its inabilities?
>
> I don't think you need to go there, Mike. The fact that they're designing
> the software from a perspective that willingly discards UNIX design
> philosophies is all you need to know. The question isn't "is it biting us
> in the arse *now*", it's will that design methodology make it virtually
> inevitable that it will? As I said, UNIX principles exist for a reason.
> Those who ignore history will be doomed to repeat it.
>
> And let's not forget that they're rejecting not one UNIX principle, but two:
> the fact that they aren't explicitly designing software that bootstraps your
> system to work reliably and robustly (by their own admission) *without* /usr
> on / is reprehensible. They could have also had the "init" process launch
> their pseudo-xinetd, service/mount monitoring, etc., separately would have
> been an acceptable choice. Make systemd a *collection* of UNIX-like
> separate components, rather than a monolithic blob.
>
> But, they didn't. And I'm not about to subject any of *my* systems to crap
> like that.
>
> --Arthur Corliss
> Live Free or Die
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Apr 6 21:12:48 2011