On Tue, Sep 9, 2014 at 1:06 PM, Armin K. <kre...@email.com> wrote: > "It does not follow UNIX Philosophy" > > Anyone who works with modern software will notice that nothing today > follows that. Even X.org (the thing everyone has installed) does more > than one thing, doesnt't use text streams (the X server is a(n) > (terrible) IPC), etc. > > The technology and software have evolved so much that UNIX Philosophy is > silly nowadays. Even the modern text editor (and I am not speaking of > VIM and alike) does more than one thing today, but still in defense you > could say that it "handles text (but does many more things in process of > doing that)", but in the same way you could say for systemd is that "it > manages your system (system and session manager as the upstream claims)". > > Speaking about anything modern that should follow the UNIX Philosophy is > just silly today. > 30 years in software development is like 1000 years > in real world. It evolves rapidly.
Speaking as someone who gets paid to develop modern software and maintain modern infrastructure I certainly haven't noticed that. In fact what I've noticed is quite the opposite: software that rejects the Unix philosophy wholesale tends to fall flat on its face pretty hard. It becomes a giant morass that tries to be everything to everyone, solves the general solution inflexibly and usually poorly, is almost impossible to interop with and leverage cleanly, and slowly but surely devolves into an unmaintainable mess that needs to be re-written and replaced. This costs my company and others a lot of wasted time, effort, and money. I've seen this argument a couple times now in relation to systemd (that the Unix philosophy is obsolete), most shockingly by an Arch Linux developer (an Arch Linux developer thinks the Unix philosophy is obsolete?!). [1] Let's recap by using the enumeration from The Unix Philosophy book: Small is beautiful. Make each program do one thing well. Build a prototype as soon as possible. Choose portability over efficiency. Store data in flat text files. Use software leverage to your advantage. Use shell scripts to increase leverage and portability. Avoid captive user interfaces. Make every program a filter. The Unix philosophy is a set of guidelines, not rigid rules. Is each tenet relevant in every situation? Of course not. But the core design principle is to have small, well defined building blocks that are easy to use and combine in interesting and powerful ways; the idea that the "whole is greater than the sum of its parts" (thanks Aristotle!). [2] This principle is IMHO a timeless truth that applies to many things, not just software development. It doesn't matter whether it's been a thousand years or a million years. You mentioned X11 a couple times, but X is the exception that proves the rule. In fact, Mike Gancarz, the author of The Unix Philosophy book (and one of the original X11 developers), cited X11 as an example of the Second System Problem. [3] X is an example of how *not* to do it, not an example of why the Unix Philosophy is obsolete. The stated vision of the systemd cabal (paraphrasing) is to usher in a post-distro world. [4] Systemd is meant to be the engine of that change. That's fine, and wanting to revolutionize the paradigm is perhaps even noble and praise-worthy... but all I wanted was a better init! "one can lose sight of the basic principles -- simplicity, clarity, generality -- that form the bedrock of good software." [5] [1] http://archlinux.me/brain0/2012/09/10/yet-another-systemd-comment/ [2] http://en.wikipedia.org/wiki/Emergence#cite_note-Meta-2 [3] Linux and the Unix Philosophy, pg. 42 [4] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html [5] http://cm.bell-labs.com/cm/cs/tpop/preface.html -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
