On 11.9.2014 2:55, Dylan Cali wrote: > On Tue, Sep 9, 2014 at 1:06 PM, Armin K. <[email protected]> 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: >
If you are talking about Arch and systemd developer, then I may know who that is. Not a very pleasant person to speak to when it comes to technical things since he seems to share some of my views too (or me his). > Small is beautiful. > Make each program do one thing well. Now, it really depends on what the "one thing" is. The definition may be different today or it may not apply to *anything* from this century that's not command line. We have several utilities such as ls, mv, cp, rm, rmdir, etc that are designed to do *one* thing and do it well. At the same time, we have a file manager (that's not necessarily a GUI file manager) that does what all of the mentioned commands do and more. But in the end, it does one thing - lets you manage your file system. > Build a prototype as soon as possible. > Choose portability over efficiency. Sometimes efficiency is more important. Why would anyone care about making code portable when it's designed to run just on top of something and is using interfaces not available anything else? I agree it may be important for higher level libraries and applications to follow this, but not for low level, system specific stuff. That's why you can't build Linux Kernel modules on top of FreeBSD or vice versa (not a really good example, but meh). > Store data in flat text files. Now this is not a bad idea, but a terrible idea. Storing anything in plain text that's not a log, pid or a configuration file is completely insane (at least in my opinion) and may result in a huge security issue. Not to mention that parsing text files is an expensive operation when it comes to large amounts of data. That's where databases come in handy (for large amounts of data) and they are binary. > Use software leverage to your advantage. > Use shell scripts to increase leverage and portability. Shell scripts are way slower compared to the actual code. This may have been useful in the UNIX era, but not really today. Nowadays, people seem to rely on interpreted programming languages. Depending on the complexity of the operation, it's cheaper to use an interpreted programming language or just C/C++/whatever code paths. Not to mention that using interpreted languages for stuff like that gives you more portability across all operating systems (you can run a python/perl/ruby/tcl script on Windows, for example, but getting bash (at least latest versions) to work there is a bit painful, not to mention that's awfuly slow compared to the interpreted programming languages). > 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. > I haven't said it's obsolete, I just said it's silly refering to it when writing modern software. But I'll rephrase that into "when writing any software that targets the actual users and not just system admins and geeks and whatsoever". Software today is way more complicated and software "market" (if I may call it like that) is way more demanding. The web browsing is common enough to be refered. To browse web, you need to have a browser that can do more than one thing, such as render pictures, play videos, play audio, render html, parse css, javascript, ajax and any other hell the modern web demands. Any modern application (as people seem to refer to the end user programs nowadays) will do more than one thing undereath. It's not possible to split it into 1000 modules whereas each module does one thing. That's where, I believe, modular programming comes in. Instead of writing thousands of small programs/modules and gluing them with shell scripts or any other matter of glue, you write a function for each specific operation you want to do and combine them into the final application. In the end, you get an application that does several things undereath that are required for app to function, but then app can do the "one thing" it was written to do. So what UNIX called writing things that do one thing and do it well may be interpreted today as writing C or any programming language modules that do the "one" thing and combining them together. Still, these things are not always "shareable" between other projects and most of the project end up reinventing the most common things to suit their case, such as config file parsing, command line options handling, etc. And now tell me how a browser project (as a matter of fact, a most complicated piece of software I know about next to the office suite) failed or became unmaintainable because it does not follow UNIX philosophy in any way (correct me if I'm wrong)? > > 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 >
signature.asc
Description: OpenPGP digital signature
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
