Hi John, KatolaZ,

(addressing both of these points, since they're related)

> It looks to me like you're trying to work backwards for a definition of
"Unix" that excludes systemd while retaining all the software that does not
adhere to that design philosophy. I think that's a bad idea-- it doesn't
help the people
> currently gutting systemd, and it gives future community members a
bureacratic tool to bully any project that isn't a domain-specific library.

> It's irrelevant whether Chromium, Openshot, Qt, and a thousand other
applications adhere to the Unix philosophy. Their designs aren't
predicated upon having elevated status in the OS. Their packaging,
bugfixing, mainenance, and
> discussion should proceed without any regard for what the definition of
Unix is.

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

Both of your sets of points are well taken. However, I'm not suggesting
that we apply the aforementioned principles to determine the inclusion
status of every piece of software. In fact, I advocate the opposite policy
for Devuan: include as many different programs as possible, and let the
user decide which ones (s)he wants.

It's certainly possible to install and run two or more email servers
simultaneously, therefore I advocate for the inclusion of both. Same for
widget sets, web browsers, window managers, etc. However, it's not
possible to install and run multiple init systems(*) simultaneously, and
moreover, one of them has to be the distro's default. Which one does the
distro select? How does the distro allocate its mainpower to integrating
different choices into the system? I put forth these principles only for
handling these cases.

>From following Debian's systemd debate, I think a lot of the flames,
rhetoric, and burn-out might have been avoided if there were a set of
design principles in place for helping developers come to consensus on how
to select a default among a set of conflicting software packages. If this
were the case, then I suspect that all the arguments would be reduced to
figuring out how well each init system candidate adhered to the design
principles--something that doesn't require a heavy emotional investment,
but does require experience in software engineering. Instead, we saw a lot
disagreement on not only how well systemd adheres to the UNIX philosophy,
but also on much more fundamental policies in Debian itself, like how
relevant the UNIX philosophy is to Debian, how desirable/undesirable it is
to have the init system tightly coupled to unrelated aspects of the OS, and
how desirable/undesirable it is to support multiple conflicting init
systems when considering how they affect the rest of the system (e.g.
excluding other kernels). My take-away from the whole ordeal is that it's
up to the distro to address these fundamental policies as part of its
constitution (or mission statement, or manifest, or whatever), so it's
clear for all relevant parties what kinds of software the distro favors.

"Do one thing and do it well" is a good start, but it's too ambiguous to be
useful. I can't tell you how many times I've seen both Debian and other
Linux users unironically say something to the effect of "systemd does one
thing well: it manages your system!", "systemd is made of multiple binaries
which each do one thing well, therefore it follows the UNIX philosophy!",
or "GNU is not UNIX, therefore the UNIX philosophy does not apply!" The
principles I put forth are meant to reduce ambiguity, and decouple any
connotations brought by the word "UNIX" from the actual design principles
Devuan's architecture would follow.

I'm not hard-set on a particular interpretation of the UNIX design
philosophy, and I certainly don't want to have it used as a tool for
bureaucratic suppression. I just think that having some agreed-upon set of
technical design principles in place before we have to deal with any
controversial system-wide design decisions would save us a lot of pain in
the long run.

-Jude

(*) I use the term "init system" loosely here. Systemd is far more than an
init system, but it competes with other programs that must run as PID 1.

On Fri, Mar 27, 2015 at 2:58 PM, 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? :)
>
> 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...
>
> 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.
>
> 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
>
> I think that the only concrete possibility is that of using a pinch of
> salt whenever the choice between different alternatives is necessary
> (if it ever is), and just go for the one that seems more reasonable,
> where by "reasonable" I mean complying with almost all the points you
> stated above, but also being in line with what a greybeard unix
> user/admin would generally expect from a unix system, which is
> something you can't just include in a bullet list ;-)
>
> My2Cents
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
>