[ale] Systemd rants (was bow head)

Fri Sep 8 12:04:10 EDT 2017

I would say for Nginx to truly fall under the "do one thing and do it well"
It would have to lose its proxy support and caching support. This means
instead of having Ngnix talk to php-fpm/gunicorn/uwsgi/passenger/etc and it
happen to cache things either to disk or RAM to speed things up you would
need to have something more like, HAProxy that talks to your
php-fpm/gunicorn/uwsgi/passenger/etc
and maybe Nginx for any static assets and if you wanted caching you would
need to throw in something like Varnish/Memcache. That way each moving
wheel is truly only responsible for doing one thing.  That is a very
contrived example I'll admit and may actually be dumb to try and deploy
which is why Nginx does all the things that it out of the box.

This is just my view on it and was just meant as an example, not to say
that any of this is right or not as at the end of the day we are talking
about a philosophy. I'm not against Nginx or Apache for that matter, both
tools get the job done although I do prefer Nginx over Apache as I find it
nicer to work with.

On Fri, Sep 8, 2017 at 11:37 AM Kyle Brieden <kyle at txmoose.com> wrote:

> I would argue that Nginx is MUCH closer to the "Do one thing" philosophy
> than apache is.  Nginx essentially only serves up static content and
> caches some of that static content in memory to serve it faster.  I
> think that falls well within the "do one thing" of serving static
> content.  Nginx doesn't do any server side processing at all;  you need
> php-fpm for php, gunicorn/uwsgi for python, etc...  Nginx passes the
> request back to those, those do the processing and hand rendered pages
> to nginx, and as far as nginx is concerned, that's a static asset that
> it fires out the front.  All HTML/CSS/JS assets that it serves are
> static content, rendered in browser.  One could argue that nginx isn't a
> "webserver" at all, although that's what it made it's name on.  It
> basically only does proxy to other things that do processing and then
> serves up static objects.
>
> On that same token, the fact that it can loadbalance and have many
> backends to proxy to falls well within the purview of "being good at
> proxying".
>
> Just my 2 cents.
>
> ---
> Very respectfully,
> Kyle Brieden
>
> On 08-09-2017 10:01, Adam Jimerson wrote:
> >> Thanks for the reminder for why I don't use either Emacs or Apache.
> >
> > 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.
> >
> > 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 lighttpd and Caddy to name a few.
> >
> > On Fri, Sep 8, 2017 at 9:25 AM DJ-Pfulio <DJPfulio at jdpfu.com> wrote:
> >
> >> 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...
> >>>>>
> >>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://mail.ale.org/mailman/listinfo/ale
> >> See JOBS, ANNOUNCE and SCHOOLS lists at
> >> http://mail.ale.org/mailman/listinfo
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170908/85b7c3d7/attachment.html>