<div dir="ltr">> <span style="color:rgb(33,33,33)">Thanks for the reminder for why I don't use either Emacs or Apache.</span><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">Sorry but that is a pretty week statement unless you use something that can only edit text/hex/whatever your working with files and/or only using a web server only capable of service static files (html, css, js, misc files, etc)/a dedicated proxy server/a dedicated caching server.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><font color="#212121">Nginx even violates the "Do one thing and do it well" as it is a web server that works well as forward/reverse proxy and it has really good caching support. Same for some of the smaller more obscure web servers like </font>lighttpd and Caddy to name a few.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 8, 2017 at 9:25 AM DJ-Pfulio <<a href="mailto:DJPfulio@jdpfu.com">DJPfulio@jdpfu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the reminder for why I don't use either Emacs or Apache.<br>
<br>
<br>
<br>
On 09/08/2017 07:58 AM, Jim Kinney wrote:<br>
> UNIX is dead. Linux isn't UNIX. It's only UNIX-like.<br>
><br>
> Emacs violates those rules. An editor that can read your email out loud<br>
> is rather crossing domains.<br>
><br>
> Apache violates those rules. The proxy capabilities are beyond it's<br>
> initial web server domain.<br>
><br>
> But at least systemd provides a topic other than vi vs emacs to squabble<br>
> over. That was getting old.<br>
><br>
> Besides, systemd follows most of the rules that were listed about as<br>
> well as any other PID 1 process responsible for a current system startup.<br>
><br>
> On September 8, 2017 7:28:45 AM EDT, Jerald Sheets <<a href="mailto:questy@gmail.com" target="_blank">questy@gmail.com</a>> wrote:<br>
><br>
> I avoid all the BS and just hate it for its design, layout, and<br>
> intrusion into all sorts of things it shouldn’t be fiddling around<br>
> in, breaking a myriad of tenets of the “UNIX way”.<br>
><br>
> The “UNIX Way” is to have a tool that does one thing, does it very<br>
> well, has clearly defined input and output and doesn’t try to handle<br>
> multiple responsibility domains.<br>
><br>
> "This is the Unix philosophy: Write programs that do one thing and<br>
> do it well. Write programs to work together. Write programs to<br>
> handle text streams, because that is a universal interface.” — Doug<br>
> McIlroy, the inventor of UNIX pipes<br>
><br>
><br>
> This is why grep doesn’t awk and vice-versa. In case we’ve forgotten:<br>
><br>
> The Rule of Modularity:<br>
> Write simple parts connected by clean interfaces.<br>
> Rule of Clarity:<br>
> Clarity is better than cleverness.<br>
> Rule of Composition:<br>
> Design programs to be connected with other programs.<br>
> Rule of Separation:<br>
> Separate policy from mechanism; separate interfaces from engines.<br>
> Rule of Simplicity:<br>
> Design for simplicity; add complexity only where you must.<br>
> Rule of Parsimony:<br>
> Write a big program only when it is clear by demonstration that<br>
> nothing else will do.<br>
> Rule of Transparency:<br>
> Design for visibility to make inspection and debugging easier.<br>
> Rule of Robustness:<br>
> Robustness is the child of transparency and simplicity.<br>
> Rule of Representation:<br>
> Fold knowledge into data, so program logic can be stupid and robust.<br>
> Rule of Least Surprise:<br>
> In interface design, always do the least surprising thing.<br>
> Rule of Silence:<br>
> When a program has nothing surprising to say, it should say nothing.<br>
> Rule of Repair:<br>
> Repair what you can — but when you must fail, fail noisily and as<br>
> soon as possible.<br>
> Rule of Economy:<br>
> Programmer time is expensive; conserve it in preference to machine time.<br>
> Rule of Generation:<br>
> Avoid hand-hacking; write programs to write programs when you can.<br>
> Rule of Optimization:<br>
> Prototype before polishing, Get it working before you optimize it.<br>
> Rule of Diversity:<br>
> Distrust all claims for one true way.<br>
> Rule of Extensibility:<br>
> Design for the future, because it will be here sooner than you think.<br>
><br>
><br>
> I’ll stick with what has worked extremely well for almost 50 years.<br>
><br>
><br>
><br>
> —jms<br>
><br>
><br>
>> On Sep 8, 2017, at 3:10 AM, Steve Litt <<a href="mailto:slitt@troubleshooters.com" target="_blank">slitt@troubleshooters.com</a><br>
>> <mailto:<a href="mailto:slitt@troubleshooters.com" target="_blank">slitt@troubleshooters.com</a>>> wrote:<br>
>><br>
>> On Thu, 7 Sep 2017 12:29:46 +0000<br>
>> "Lightner, Jeffrey" <<a href="mailto:JLightner@dsservices.com" target="_blank">JLightner@dsservices.com</a><br>
>> <mailto:<a href="mailto:JLightner@dsservices.com" target="_blank">JLightner@dsservices.com</a>>> wrote:<br>
>><br>
>>> Caveman conversation:<br>
>>> Ug: What that?<br>
>>> Zog: Wheel.<br>
>>> Ug: Why wheel? Drag work for years.<br>
>>> Zog: More fast to use wheel.<br>
>>> Ug: Wheel made by false god to trap draggers. It bad.<br>
>>> Ug then clubs Zog because Zog doesn't see the intrinsic "reason" of<br>
>>> Ug's opinion.<br>
>>><br>
>>><br>
>>> Move ahead 10,000 years:<br>
>>> Ug: What that?<br>
>>> Zog: Systemd.<br>
>>> Ug: Why systemd. Init work for years...<br>
>>><br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>