Great list! Thanks everybody for your input, because for those of us who
aren't programmers, this helps clarify a lot of the reason why systemd is
less than ideal from a technical perspective. I'm more of a "if I can't
read it or write it in vi or manipulate it via a bash script, then it
doesn't belong in Linux" kind of guy, and I believe the reason why I have
such disregard for systemd is evident in the aforementioned statement. I
don't need to write a conf file that is actually a wrapper to a piece of
code that then configures how my machine runs, all the while with me having
no insight to what is going on inside; and yes, I'm aware this is a gross
simplification. However, your list and consequent addendums are great food
for thought. Educating the masses with fact, logic, and just plain old
good common sense is the only way to combat the idiocracy that the Linux
community as a whole has become. Thanks again!

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obeardly@???

On Tue, Mar 31, 2015 at 1:00 PM, Steve Litt <slitt@???>
wrote:

> 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

>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>