[ale] Systemd rants (was bow head)

Adam Jimerson vendion at gmail.com
Fri Sep 8 10:09:49 EDT 2017


As for the BSDs they are great (personal bias) but I would consider them
more of a UNIX clone/successor than anything at this point. Also even the
BSDs are not safe from breaking the "Do one thing..." philosophy  there
have been multiple attempts to port/add something SystemD/LaunchD like to
at least FreeBSD, don't remember about any of the other BSDs.

On Fri, Sep 8, 2017 at 10:01 AM Adam Jimerson <vendion at gmail.com> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170908/1f78080b/attachment.html>


More information about the Ale mailing list