:: Re: [Dng] [OT] Debian problems with…
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Sat, 28 Feb 2015 01:42:49 -0500
"Steven W. Scott" <codekraken@???> wrote:


> On Feb 27, 2015 11:45 PM, "Steve Litt" <slitt@???>
> wrote:
>
> > On Fri, 27 Feb 2015 14:18:15 -0600
> > "T.J. Duchene" <t.j.duchene@???> wrote:
> >
> >
> > > With respect to all, I think that a measure of objectivity is
> > > called for here. I think that because personality clashes that
> > > Debian's entire systemd discussion has lost any sense of reality
> > > long ago.
> >
> > You know, T.J., I might just agree with you, *if* you can show me a
> > block diagram of the systemd ecosystem, *complete with interaction
> > lines as well as functional blocks*.
> >
> > You know, like this:
> >
> > http://troubleshooters.com/lpm/201202/images/email_arch_personal.png
> >
> > Or these:
> >
> > http://troubleshooters.com/lpm/200803/images/server_app.png
> > http://troubleshooters.com/lpm/200803/images/client_app.png
> >
> > Or these:
> >
> > http://www.troubleshooters.com/linux/djbdns/images/mm_process_overview.png
> > http://www.troubleshooters.com/linux/djbdns/images/mm_daemontools.png
> > http://www.troubleshooters.com/linux/djbdns/images/mm_minimal_service.png
> >
> > http://www.troubleshooters.com/linux/djbdns/images/mm_dnscache_block_diagram.png
> >
> > http://www.troubleshooters.com/linux/djbdns/images/mm_tinydns_block_diagram.png
> >
> > Or this:
> >
> > http://www.troubleshooters.com/linux/nullmailer/images/nullmailer_mm.png
> >
> > But not the following, because it's boxes with no lines:
> >
> >
> > http://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Systemd_components.svg/440px-Systemd_components.svg.png
> >
> > Nor this, because it's obviously incomplete as a representation of
> > the systemd ecosphere:
> >
> >
> > http://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg/440px-Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg.png
> >
> >
> > Bottom line is this: If you make a modular system with thin
> > interfaces and sane components, somebody will make a block diagram
> > representing it, accurately, in its entirety.
> >
> > It could be argued that the email, sockets, and djb software
> > systems I diagrammed were much simpler than systemd. Fair enough,
> > but I'm one guy doing this stuff in my spare time, not six guys
> > getting paid full time by Red Hat. I'm sure one of the geniuses Red
> > Hat hired could have diagrammed system accurately and completely.
> > Heck, I often do that *before* I write software, just so the system
> > turns out architecturally sound.
> >
> > Let's see the block diagram. Prove systemd doesn't have grave
> > architectural problems.
> >
> > SteveT
> >
> > Steve Litt                *  http://www.troubleshooters.com/
> > Troubleshooting Training  *  Human Performance



> Lol! I recently happened to be researching the different soundsystem
> architectures, after incinerating pulseaudio on my laptop/Wheezy and
> then having different problems, and found -->
> https://wiki.debian.org/Sound
>
> What struck me of particular interest were the three diagrams of how
> alsa/jack/pulseaudio perceive the sound architecture. I couldn't help
> but think that systemd very likely has the same structure. The
> "mother, may I?/None shall pass/TRON MCP" structure.
>
> Developers often hang to a general pattern of designing things; I
> cant see why the designer behind pulseaudio would be different. Best
> argument against systemd I've seen to date.
>
> SWS


Hi Steven,

First, thank you *so much* for providing these three diagrams. I've
been trying to find out how sound works for a long time.

As far as
http://upload.wikimedia.org/wikipedia/commons/thumb/0/00/Pulseaudio-diagram.svg/1000px-Pulseaudio-diagram.svg.png ,
if systemd had a block diagram like that, and if the boxes truly
represent modules and not just concepts, I would stipulate that T.J.
might have a point, because that diagram is actually something I could
troubleshoot off of, always assuming the arrows between them represent
thin, clean interfaces.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance