On Tue, 31 Mar 2015 09:11:54 -0400
Hendrik Boom <hendrik@???> wrote:

> On Tue, Mar 31, 2015 at 11:16:02AM +0200, Martin Steigerwald wrote:
> >
> > [1] [systemd-devel] I wonder… why systemd provokes this amount of
> > polarity and resistance:
> >
> > http://lists.freedesktop.org/archives/systemd-devel/2014-September/thread.html
>
> The discussion here contains a quotation about the Unix philosophy
> (in an attempt to explain how systemd follows it). I find it
> summmarises well the way Devuan believes a Linux system should be
> organised:

Allow me to make a couple small enhancements. Please keep in mind that
I use "TS" to mean "Thin, Standard", where a standard interface is a
pipe, named pipe, fifo, socket, simply structured file, etc. When I
insert something, I'll use square brackets. When I delete something,
I'll use X{whatever deleted text}.

>
>
> 1. Write simple parts connected by clean

[TS]

> interfaces.
> 2. Clarity is better than cleverness.
> 3. Design programs to be connected to other programs

[by TS interfaces]

[3a Connect programs only on a need to know basis, where the connected
program is purposed primarily to do what the connected program needs
done. Don't connect to a bicycle just to get a spoke.]

[3b If the connecting program, at various locations, requires various
types of services from the connected program, it might be OK to
violate 3a. This might, in some cases, justify connecting to GTk and
Qt.]

> 4. Separate policy from mechanism; separate interfaces
> from engines.
> 5. Design for simplicity; add complexity only where you
> must.
> 6. Write a big program only when it is clear by demonstration
> that nothing else will do.
> 7. Rule of Transparency: Design for visibility to make inspection and
> debugging easier.
> 8. Robustness is the child of transparency and simplicity.
> 9. Fold knowledge into data so program logic can be stupid and robust.
> 10. In interface design, always do the least surprising thing.
> 11. When a program has nothing surprising to say, it should say
> nothing.
> 12. When you must fail, fail noisily and as soon as possible.
> 13. Programmer time is expensive; conserve it in preference to
> machine time.

[13a. Unless doing so would make life slower for users and admins, in
which case your top priority should be saving time for the users and
admins.]

> 14. Avoid hand-hacking; write programs to write programs when you can.
> 15. Prototype before polishing. Get it working before you optimize it.
> 16. Distrust all claims for “one true way”.
> 17. Design for the future, because it will be here sooner than you
> think.

I think my modifications go a long way toward rejecting faux modularity.

SteveT

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