:: Re: [Dng] Devuan commitments - will…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Steve Litt
Date:  
À: dng
Sujet: Re: [Dng] Devuan commitments - will trade-off be applied?
On Fri, 27 Mar 2015 18:58:45 +0000
KatolaZ <katolaz@???> wrote:

> On Thu, Mar 26, 2015 at 06:53:54PM -0400, Jude Nelson wrote:
>
> [cut]
>
> >
> > I took a stab at stating what "Unix software design philosophy"
> > means earlier up the thread, but I'll reproduce it here for your
> > convenience:
> >
> > """
> > 0. A program is a file that contains executable data (e.g. a
> > binary, a script, or a library).
> > 1. Each program has a single well-defined responsibility.
> > 2. If two programs have orthogonal responsibilities, then they are
> > logically independent of one another's implementation (i.e.
> > programs with orthogonal responsibilities are not coupled to each
> > other's implementations).
> > 3. Functionality encompassing multiple responsibilities is obtained
> > by composing two or more programs (such as through piping, I/O
> > redirection, dynamic linking, and so on).
> > """
> >
>
> Hi Jude,
>
> yours are very good and solid points, but unfortunaely they are not
> that useful in practice. Point 1 can be a problem for many software
> packages/suites which deal with more than one thing. An example is a
> desktop manager: would it be considered DOTATIW-compliant? :)


There's no DOTATIW in Wikipedia, and the first 10 entries in Google had
nothing remotely to do with this, so I think you'll need to spell it
out. I suspect after some thought you meant dotaDiw. But anyway, in
answer to your question, it could be said that a desktop does one thing:
Provide a GUI interface between OS and human. If, for instance, a
desktop does two things, it ideally should be composed of two very
separable (and individually replacable) parts. For instance, IIRC LXDE
comes with OpenBox as a window manager, but you can swap in a different
window manager and still have LXDE's "desktop" behavior.

>
> Point 2 has problems as well, because sometimes a package contains
> several programs (the first example that comes to my mind is postfix,
> but you have thousands of other examples out there) which are
> orthogonal yet highly dependent on each other's implementation. And
> none of us would like to say that postfix is overall not
> DOTATIW-compliant...


AFAIK, postfix transfers email. That's the one thing it does. Doing
that rather inclusive job requires many components to do parts of the
job. Hence the many programs. In addition, I'm sure there are many
plugins you can add to Postfix. That's fine, and the plugins are
voluntary, and presumably all they do is add a capability or an
interface to something else.

Another example: Consider a shellscript that presents stats from your
web log, in text (not gui) format. That's one thing. But consider that
to do this one thing, you'd probably perform two subtasks: 1) parse the
raw log into a nice, sortable format, and 2) convert from that into a
proper and sorted format. Each of 1 and 2 is on thing, done well.
Assuming the structure of the intermediate file is documented and
respected, either 1 or 2 could be replaced without affecting the other.

Also consider that there would be multiple #2's: One for each type of
report. Each #2 does one thing and does it well.

The problem comes in when either #1 or #2 must interface with the init
system. Or your music player. These are what Jude calls orthogonal.
They're just thrown in for the hell of it. Or thrown in to make it
harder for competing distros to compete.

>
> Point 3 might be problematic as well, not just in the case of postfix
> (which does not use piping or I/O redirection for inter-process
> communication), but in hundreds of other programs that I am sure you
> will consider definitely DOTATIW-compliant, but do not follow under
> point 3 above.


I think if you take Jude's "and so on" to mean thin, well defined,
universally availble interfaces including, but not limited to, sockets,
fifos, file system, signals, etc, then Jude's #3 comes pretty close.

>
> In a word: stating a policy here is quite difficult, if not
> impossible, and would soon require a relatively large number of
> exceptions and smallprints in order to include software that you and
> me and almost everybody here already would agree is DOTATIW- and
> KISS-compliant. To rephrase an old saying, we can say that
> DOTADIW-compliance is like pornography: you can't define it precisely,
> but you immediately recognise it as soon as you see it ;-P


True, but I think Jude's four principles are an ideal starting point
that will require less interpretation and exceptions than most others.

SteveT

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