[ale] Systemd rants (was bow head)

[DJ-Pfulio]

Thanks for the reminder for why I don't use either Emacs or Apache.



On 09/08/2017 07:58 AM, Jim Kinney wrote:
> UNIX is dead. Linux isn't UNIX. It's only UNIX-like.
> 
> Emacs violates those rules. An editor that can read your email out loud
> is rather crossing domains.
> 
> Apache violates those rules. The proxy capabilities are beyond it's
> initial web server domain.
> 
> But at least systemd provides a topic other than vi vs emacs to squabble
> over. That was getting old.
> 
> Besides, systemd follows most of the rules that were listed about as
> well as any other PID 1 process responsible for a current system startup.
> 
> On September 8, 2017 7:28:45 AM EDT, Jerald Sheets <questy at gmail.com> wrote:
> 
>     I avoid all the BS and just hate it for its design, layout, and
>     intrusion into all sorts of things it shouldn’t be fiddling around
>     in, breaking a myriad of tenets of the “UNIX way”.
> 
>     The “UNIX Way” is to have a tool that does one thing, does it very
>     well, has clearly defined input and output and doesn’t try to handle
>     multiple responsibility domains.
> 
>     "This is the Unix philosophy: Write programs that do one thing and
>     do it well. Write programs to work together. Write programs to
>     handle text streams, because that is a universal interface.” — Doug
>     McIlroy, the inventor of UNIX pipes
> 
> 
>     This is why grep doesn’t awk and vice-versa.  In case we’ve forgotten:
> 
>     The Rule of Modularity:
>     Write simple parts connected by clean interfaces.
>     Rule of Clarity:
>     Clarity is better than cleverness.
>     Rule of Composition:
>     Design programs to be connected with other programs.
>     Rule of Separation:
>     Separate policy from mechanism; separate interfaces from engines.
>     Rule of Simplicity:
>     Design for simplicity; add complexity only where you must.
>     Rule of Parsimony:
>     Write a big program only when it is clear by demonstration that
>     nothing else will do.
>     Rule of Transparency:
>     Design for visibility to make inspection and debugging easier.
>     Rule of Robustness:
>     Robustness is the child of transparency and simplicity.
>     Rule of Representation:
>     Fold knowledge into data, so program logic can be stupid and robust.
>     Rule of Least Surprise:
>     In interface design, always do the least surprising thing.
>     Rule of Silence:
>     When a program has nothing surprising to say, it should say nothing.
>     Rule of Repair:
>     Repair what you can — but when you must fail, fail noisily and as
>     soon as possible.
>     Rule of Economy:
>     Programmer time is expensive; conserve it in preference to machine time.
>     Rule of Generation:
>     Avoid hand-hacking; write programs to write programs when you can.
>     Rule of Optimization:
>     Prototype before polishing, Get it working before you optimize it.
>     Rule of Diversity:
>     Distrust all claims for one true way.
>     Rule of Extensibility:
>     Design for the future, because it will be here sooner than you think.
> 
> 
>     I’ll stick with what has worked extremely well for almost 50 years.
> 
> 
> 
>     —jms
> 
> 
>>     On Sep 8, 2017, at 3:10 AM, Steve Litt <slitt at troubleshooters.com
>>     <mailto:slitt at troubleshooters.com>> wrote:
>>
>>     On Thu, 7 Sep 2017 12:29:46 +0000
>>     "Lightner, Jeffrey" <JLightner at dsservices.com
>>     <mailto:JLightner at dsservices.com>> wrote:
>>
>>>     Caveman conversation:
>>>     Ug:  What that?
>>>     Zog:  Wheel.
>>>     Ug:  Why wheel?  Drag work for years.
>>>     Zog: More fast to use wheel.
>>>     Ug: Wheel made by false god to trap draggers.  It bad.   
>>>     Ug then clubs Zog because Zog doesn't see the intrinsic "reason" of
>>>     Ug's opinion. 
>>>
>>>
>>>     Move ahead 10,000 years:
>>>     Ug:  What that?
>>>     Zog:  Systemd.
>>>     Ug: Why systemd.  Init work for years...
>>>