Linux and the Unix Philosophy

limbo_14 writes "Mike Gancarz takes his oft'-quoted original book, The Unix Philosophy and spruces it up for the Brave New World of Linux with Linux and the Unix Philosophy. Since The Unix Philosophy was written, Unix has undergone many changes and evolutions. Now with Linux emerging as the new face of Unix, he has updated his book with the same philosophy and tenets that were in the first, but updated the book to include considerations for the Open Source community and the new world of Operating Systems in which we live." Even the old version of The Unix Philosophy is worth finding; it may remind you of Neil Stephenson's In the Beginning Was the Command Line. Read on for the rest of limbo_14's review. Linux and the Unix Philosophy author Mike Gancarz pages 200 publisher Butterworth-Heinemann rating Recommended reviewer limbo_14 ISBN 1555582737 summary An updated and expanded version of Gancarz's original book, The Unix Philosophy.

The good stuff... I enjoyed Mike Gancarz' first book The Unix Philosophy greatly when I was first getting into the Unix world, and was hoping for an updated version. The thing that makes this book stand out in the shelves full of How-To, Dummy, and Administrator guides is the fact that it covers the What and Why of Unix/Linux rather than the How's. I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms.

I realized the importance of this book after reading it, and being forced to do interviews for a Unix Engineer at my office. Of the 7 candidates, 6 of them seemed to know the textbook stuff. They knew the commands, they knew vi and a handful of scripting languages to a degree of proficiency. Alas, this is what it takes to become a Unix Administrator, not an Engineer that needs to see the whole picture. In this world of "puppy mill" Unix admins who have certifications and know one or two flavors of Unix/Linux, this book really teaches people the core of why Unix/Linux is the way it is, and why it is so attractive to those who really care about which OS to use.

The last chapter -- "Brave New (Unix) World)" -- is the real kicker. Gancarz really drives it home, and shows how the Unix/Linux philosophy has made it into other aspects of technology, and in the world we live in.

The not-so-good stuff ... With every good book, there must be some bad, although this one's errors are quite forgivable. Although I appreciate any book that loosens the RFC style nature of so many technical books, sometimes it can go a little too far. This, however, is for each reader to judge. Some of the puns made me squirm, but for the most part they added a nice touch of levity to the book. So, depending on your threshold for python-esque puns or corny Elvis jokes, the book may not be for you, but knowing the /. Crowd, I don't think it will cause anything more than some groans and giggles. All in All... This is a quality book. It is one that should be re-read every now and then to make sure you do not stray from the Tenets that Gancarz drives home throughout the book via anecdotal evidence.This book can and should be read by anyone from a newbie hacker to a Corporate CEO. It is just technical enough not to make one feel patronized, and eases you into it with general concepts just enough to make it not feel like reading IETF standards. Here are the chapters, which give a good overview of what each is about:

• Table of Contents
• The Unix Philosophy: A Cast of Thousand
• One Small Step for Humankind
• Rapid Prototyping for Fun and Profit
• The Portability Priority
• Now THAT'S Leverage!
• The Perils of Interactive Programs
• More Unix Philosophy: Ten Lesser Tenets
• Making Unix Do One Thing Well
• Unix and Other Operating System Philosophies
• Through the Glass Darkly: Linux vs. Windows
• A Cathedral? How Bizarre!
• Brave New (Unix) World

Although this is not the cheapest book in the rack, it packs more of a punch than half of the books on my shelf, so I think it is worth it. I found it a great read on the metro on the way to work in the morning, and found myself finishing it well within a week. With 200 pages, and by making it fun to read, Linux and the Unix Philosophy breezes by and makes for a great read.

You can purchase Linux and the Unix Philosophy from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Tragically,

[burgburgburg]

SCO has determined that this book has violated it intellectual property. While you can buy the book, you require an additional SCO license to read the book. That'll be $699.

Re:Tragically,

[Namaseit]

No, thats $699 per page. An honest mistake, that will cost you $200.

Re:Tragically,

[JimPooley]

Tragically, if Slashdot is still around in 10 years, and SCO is not, people will STILL be doing fucking lame jokes about SCO.
Funny, my arse...

HTML and the UNIX commandments...

[jared_hanson]

1. Though shalt end your italic tags.

Re: HTML and the UNIX commandments...

[gidds]

If you're going to use archaic English, at least do so properly! The archaic second-person-singular nominative pronoun is spelled thou; and it takes a corresponding singular possessive: thy (or thine before a vowel, as in this case). Not 'your'. (Half a mark for correctly using the corresponding verb form, 'shalt', though.)

And anyway, what's the problem? All the italics seem properly localised. Has the article been edited since your post?

This guy is crazy....

[Lord_Slepnir]

First, you have a book about the philosophy of an operating system. Then I noticed that there was a chapter called "Rapid Prototyping for Fun and Profit". This guy is either brilliant, or burned out his brian on LSD in the 70s.

Now that I think of it, the two things Berkley is famous for is UNIX and LSD, and I dont' think it's a coincidence.

Something I've never been able to figure out.

[Anonymous Coward]

Some of the major tenets of the original UNIX philosophy were:

- Small is beautiful.

- Make each program do one thing well.

Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?

Some of the best examples are sendmail and emacs. And no, this isn't a troll. But I just don't understand why such people just don't get it. Clearly it isn't a lack of intelligence.

But this paradox is something which I've never been able to figure out.

Re:Something I've never been able to figure out.

[Planesdragon]

Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?

Because it's old and out of date. The new ideals should be:

- Stable is beautiful

- Make each program do what it does completely.

Few folks enjoy puny programs that do one thing very well--when they want to do something slightly different, they wind up using a bunch of differenet tools.

Also, the advent of windowing, color, and richly formated files has made "small simple programs" too hard to use. A whole new set of "single-task, fast-running" programs would be nice--but they'd have to be designed from the ground up to (1) work together and (2) work with richly formatted (XHTML) files.

'course, the end-user wouldn't see distinct programs--they'd ideally just see their computer, and do what they want to without ever having to think about tasks, programs, or appellets ever again.

Re:Something I've never been able to figure out.

[aussersterne]

when they want to do something slightly different, they wind up using a bunch of differenet tools

Ah-ha! A light bulb has gone off over your head. That is th point of the Unix philosophy.

Thanks to the Unix philosophy, when someone wants to do something slightly different, they won't need to install a new, slightly different application; they can select different arrangements of tools from their existing collection to solve almost any problem imaginable.

With the "one complete tool, one complete problem" philosophy, every I have a new problem, I must acquire an entirely new tool. If I have a problem no one else has ever had before, no tool will exist yet, and I must either create it myself or pay someone to create it for me. I must then learn and/or be trained to use it.

By attacking problems with small, specialized tools that I am very familiar with, (i.e. by splitting a problem into many smaller, more specialized sub-problems), I can use the same basic Unix toolset to solve arbitrary problems of almost arbitrary complexity.

Almost anything can be accomplished with bash, perl, awk, and the collection of shell tools and command-line networking tools on a Linux/Unix system. And if you need some functionality that the tools can't provide, you don't need to install a 100% beginning-to-end solution complete with duplicate functionality and learning curve, you install a new small, specialized tool (i.e. gphoto2 to fetch photos from a camera) to solve the 1% of the problem that needed a new tool and use the tools you already know and have for the other 99% of the problem.

Efficiency and flexibility are key in Unix.

Some people argue (as you have) that these come at the expense of ease of use, but that is only true for small (admittedly often consumer-oriented) problems. Without doubt, however, past certain threshold values of problem size and complexity, efficiency and flexibility (i.e. small and specialized teams of scriptable tools) drastically increase ease of use relative to other methods, not to mention time and expense to deployment.

Re:Something I've never been able to figure out.

[Planesdragon]

That is [the] point of the Unix philosophy.

Sort of. The "UNIX philosophy" has some very good elements in it--but it's not without its flaws.

The biggest one, IMO, is getting a tool changed and automating multiple computer tasks to one human-task.

And if you need some functionality that the tools can't provide, you don't need to install a 100% beginning-to-end solution complete with duplicate functionality and learning curve, you install a new small, specialized tool (i.e. gphoto2 to fetch photos from a camera) to solve the 1% of the problem that needed a new tool and use the tools you already know and have for the other 99% of the problem.

Depends on the problem, what what your current state of learning is. (Don't toss around statistics that you don't have--we have perfectly good words for "majority" and "minority")

As I said, the problem is the advent of the GUI and the commonality of richly formatted documents--two major elements of modern computer usage that weren't really dealt with when the orignal UNIX system was created. For some modern applications, such as working with pictures, small apps added to the old apps can work. For other applications, such as 3D design, the current suite of small apps don't work.

Some people argue (as you have) that these come at the expense of ease of use, but that is only true for small (admittedly often consumer-oriented) problems.

A minority ("1%") of computers are used to solve problems. Most computers in service today are used to replace pen & paper, communicate, or play games. And most of these computers are used in a GUI environment, never (or almost-never) using the command line.

I would love to see a removal of the division between "command line" and "GUI", just as I would love to see a removal of the user-distinction between "programs" and "tasks" et al.

Re:Something I've never been able to figure out.

[imhotep1]

There are tradeoffs to using the make each program do one thing vs. make each program do everything technique.

I am currently working on a small web content management CGI in C, based on the "small is beautiful / Make each program do one thing," paradigm. It is made of several smaller programs, each does one thing (one part is the CGI, and recieves the request and returns the output, one part is an XSLT transform engine, one part is a cacheing engine that will cache the XSLT output and only rerun the XSL transform if the source file has changed, and so on and so fourth)

I am mostly doing this for self education, but I have noticed that along with the several advantages to my approach (flexibility in application and extensibility,) there are significant drawbacks.

There is processor overhead to loading each program, and while on a server with few hits this will not be an issue, I am positive that my little CMS will pale in comparison to something like MOD_PERL + some random CMS under Apache. Mine is smaller, simpler, more Unix-like, but not nessecarily better.

I think the Unix ideals are good design technique, and should be kept in mind when designing any project, but a systems designer needs to be prepared to drop them if they impede in the performace of the final application.

Think of programs like cars. Formula one race cars are horribly designed taxis. They also absolutly CANNOT handle going off road. Tis doesn't mean they are poorly designed.

Re:Something I've never been able to figure out.

[joeytsai]

I'd agree abiout emacs, and indeed tried to convince ESR that emacs goes against the Unix philosophy for his TAOUP book, although he wasn't having any of it.

Well, he at least has a section on that discussion (here) but in line with ESR's other writings, what it lacks in content in makes up in verbosity and self promotion.

Re:Something I've never been able to figure out.

[Cato]

Actually, virtually anything can be done using just Perl - the whole point of creating it was to have a single tool that could do what people did with awk, shell, sed, and many C programs, without the impedance mismatch problem. Shell scripting is great for whipping up a very quick solution, but you usually reach a point at which Perl/Python would be better. I once wrote a simple 4GL compiler entirely in shell and sed, so I think I went well beyond that point - my only defence is that Perl wasn't available then ...

Re:Something I've never been able to figure out.

[crucini]

One only has to look at GNOME and KDE to see how much the Unix landscape has been infiltrated by people that just don't get it.

While I understand where you're coming from, that isn't quite fair. KDE and Gnome appear to be attempts to produce a Windows-style GUI atop Linux. This doesn't mean the developers don't get it - it could mean that they get it and yet prefer a Windows-style GUI for some or all tasks. Or that they see a need for such a GUI to let "normal" people use Linux.

Subjectively, I feel the same alienation you are expressing from KDE and Gnome.

Re:Something I've never been able to figure out.

[javamutt]

While I do agree that there has been a lot of infiltration of people who "don't get it" in the *NIX space, I don't agree with you when this argument is applied to the desktop space.

I find that having a desktop that works in an intuitive way, unifies commonly used utilities, and makes common tasks (DnD) more efficient enhances my productivity and acts as a "blanket" around the normal activities I do.

I don't think any one philosophy dominates in ALL situations. CHOICE dominates in my opinion. In other words, on my GNOME linux box I can use a terminal to create a really efficient set of logins where I automate things and pipe lots of small tools together. BUT I can also run Evolution to read mail instead of using Perl scripts to parse my mail spool.

Of course, I can do nearly the same things on WindowMaker instead of GNOME/KDE, but I think the two are close enough in this context not to kill my point.

What's important in mastering an OS is learning its strengths and weaknesses. I think this is Linux's strength - it's like the OS Borg - assimilating the cool features of all platforms. From your statement I would suggest that you may have taken too much of an extremist stance to objectively review the pros/cons.

Re:I'll take a shot at it

[tuffy]

UNIX = Commercial way of thinking and doing business from a software standpoint, extended to the hardware aspect (by tieing the commercial, closed software to certain hardware). The old way, it is no doubt dying.

Unix started as a way to run a non-vender-supported OS on cheap PDP-11s. Unix eventually became highly commercialized and proprietized, but it started life as a hobbyist project (of sorts).

Submission guidelines?

[garcia]

Some of the puns made me squirm, but for the most part they added a nice touch of levity to the book. So, depending on your threshold for python-esque puns or corny Elvis jokes, the book may not be for you, but knowing the /. Crowd, I don't think it will cause anything more than some groans and giggles.

This is a quality book. It is one that should be re-read every now and then to make sure you do not stray from the Tenets that Gancarz drives home throughout the book via anecdotal evidence.

Are these two items REQUIRED for book reviews on Slashdot? The word "andecdotal" and "puns"?

Doesn't seem like it. :)

Where's the Beef?

[TTop]

This review basically consisted of one paragraph describing the book and a table of contents. I didn't get a real good feel of what to expect from the book. Why is it like In The Beginning?

I guess I was hoping for a little more detail about why this book is good other than "it's not man pages or RFCs."

EveryThing2

[vasqzr]

Mike Gancarz's book The UNIX Philosophy (Digital Press, 1995) describes many of the ideas and conventions that have made unix a great sytem. It starts with a short run down of the history, quickly getting to the meat of things, discussion of the major ideas of Unixdom and illustrations of why they are such good ideas. While many of the ideas may seem relatively obvious to anyone who's worked with the system before, it makes an excellent introduction to the traditions of the Unix world, as well as an excelent bit of advocacy for why the Unix way is the Right Way.

Listed in the first chapter, the following nine points are the key tenets:

Small is beautiful
Make each program do one thing
Build a prototype as soon as possible
Choose portability over efficiency
Store numerical data in flat ASCII files
Use software leverage to your advantage
Use shell scripts to increase leverage and portability
Avoid captive user interfaces
Make every program a filter ...and the ten lesser points:
Allow the user to tailor the environment:
Make operating system kernels small and lightweight:
Use lower case and keep it short
Save trees
Silence is golden
Think parallel
The sum of the parts is greater than the whole
Look for the 90 percent solution
Worse is better
Think hierarchiacally

Re:EveryThing2

[Jon Peterson]

Small is beautiful
All program names 4 chars please

Make each program do one thing
But provide for it to do that thing in 52 different ways.

Build a prototype as soon as possible
And then stop.

Choose portability over efficiency
Remember that you are only interested in porting to other Unix systems.

Store numerical data in flat ASCII files
So much for small being beautiful

Use software leverage to your advantage
Err, whatever.

Use shell scripts to increase leverage and portability
While simultaneously decreasing maintainability!

Avoid captive user interfaces
Preferably by not having any user interfaces.

Make every program a filter
Especially the 'shutdown' command. ...and the ten lesser points:

Allow the user to tailor the environment:
Sure saves you having to figure out what works.

Make operating system kernels small and lightweight:
But keep them monolithic, Linus!

Use lower case and keep it short
Keep those commands under 5 characters!

Save trees
And don't bother with manuals!

Silence is golden
Don't waste time with error output. Or other human beings.

Think parallel
Yeah, don't chain those commands together with pipes, run them all at once. Oh, hang on...

Look for the 90 percent solution
And then quit your job. Heh, let the next guy finish it.

Worse is better
0 is 1, too.

The Unix Philosophy

[cperciva]

The Unix Philosophy can be stated in several ways:

"Small interconnecting components"
"Never use one program where you could use several"
"Plumbing is good"

If is a continual source of amazement to me that GNU tools (eg, tar -AcdrtuxbBCfFGhijykKlLmMnNoOpPRsSTIUvVwWXZz7) are widely used despite this.

Re:The Unix Philosophy

[AveryT]

Tell me about it. I remember practically being flamed on a mailing list for proposing the use of find and grep to recursively search for a pattern in a hierarchy of files. Sure grep -r would have done the job in that particular case but once you add the slightest variation you have to go to find.

I definitely feel that GNU/Linux has moved away from the "true" Unix philosophy with this kitchen sink mentality.

Is the Unix philosophy real?

[GGardner]

I've been using Unix for 20 years, and can write some mean shell scripts. I've read all the original papers which talk about how great it is to have many small tools and little languages which you can hook up via pipes. That sounds great on paper, but I've never really seen it work out in practice.

Sure, we've all writing massively pipeline shell one-liners to do day-to-day tasks, but these are just one-time, throw-away code. All of my real Unix apps that I use every day are huge monolithic applications, not a composition of many tiny apps connected by pipes. My web browser is a monolithic app, not connected by pipes. GCC is a couple of monolithic applications, optionally connected by pipes, but never reconnected in any useful way (cpp notwithstanding). My newsreader and mailreader again, monolithic applications. My MTA, again, a monolithic application. Not one large program I use is a shell script, or collection of small, interchangeable programs.

So, is this Unix tool philosophy useful for real applications, or just for little shell scripts?

Re:Is the Unix philosophy real?

[dodell]

Does IPC count as a pipe? Do you run any filters on your email? How many times have you run | grep (granted that this is a one time thing)? I have a good number of shell scripts I use (for sed scripts, for instance) that make use of pipes (not extensively though). I'd suggest that pipes are used much more than you give credit for here.

Re:Is the Unix philosophy real?

[Ed Avis]

Your post sounds a lot like Miguel's 'Unix sucks' talk where he explains that Unix does not (or did not) have much reusable code and components at a level finer than whole processes - apart from a few libraries like libc and libX11 which are mostly static. Microsoft Office, sometimes the canonical Slashdot example of an ugly monolithic application, is in fact built from many small components (though for legal reasons it is hard to reuse them). The GNOME project set out to change this, although nowadays the emphasis is more on the GUI than on the component architecture.

Part of the problem is that nobody can agree on anything. So a MIME parsing library has to be written one in Emacs Lisp for Emacs, once as a Perl module, once in Python, as a C library (probably several C libraries), in Java, etc etc. Nobody can agree to write a reusable component once to a common interface (the implementation could be in any language, as long as the interface is usable from others) and just wrap that. On the other hand some libraries, often those coming later in Unix history, do have a single shared implementation, eg libpng.

When is it Unix and Not Unix?

[peter303]

Avoiding Stallman's pun, what exactly is UNIX? Does Linux qualify? Apple OS X+? Exotic OS's like Mach?

In the mid-1980s an industrial/governemnt consortium tried to defined an unified UNIX API, called Posix. Then it would be straight forward to implement the UNIX utilities, command user interfaces, and apps on top this. I recall some companies layering Posix on top of VMS, MVS, and other non-UNIX kernals. Are these UNIX?

Another approach was extending the UNIX philosophy of a simple machine image to more modern computers than those in the early 1970s. Mach assumed a computer model with multiple CPUs and memory subsystems. BeOS assumed a computer model where multimedia was the norm. So are these OS's "more UNIX-like than UNIX" then?

Lacking -- I have (many) more questions

[dodell]

I found this review to be lacking in content. It doesn't discuss the content of the book to any extent; instead it talks about how it got him a job promotion to UNIX Engineer. How did it do this? What did you learn from the book that gave you such an additional skillset to be promoted to UNIX Engineer? What are the differences between the UNIX Administrator and the UNIX Engineer you are referring to?

I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms.

I've not found any books that are mostly printed man pages. Nor have I found any circumstances where the man pages don't cover things I need to know. In any case, what parts of UNIX does it explain? Is it explaining Linux or UNIX? What OS "paradigms" are you referring to? You are going by this definition aren't you?

I realized the importance of this book after reading it, and being forced to do interviews for a Unix Engineer at my office.

What importance did you realize this book serving after you had read it? Are you sure this gave you applicable knowledge to separate "UNIX Administrators" from "UNIX Engineers"? What is the difference here?

Although I appreciate any book that loosens the RFC style nature of so many technical books, sometimes it can go a little too far.

Why? If it's discussing that you need to know an RFC to understand why something works the way it does (you've stated that this book talks more about the why than how), how does it make it "not-so-good"?

So, depending on your threshold for python-esque puns or corny Elvis jokes, the book may not be for you...

Do the few puns in the book really take that much of the quality away?

I don't think that this book should be re-read from time to time. I think new editions should be published as UNIX and Linux continue to evolve in their own separate directions (yes, they're going in somewhat separate directions).

Your listing of the TOC didn't give me any idea about what was covered? WTF is "Now THAT'S Leverage" about? What "Lesser Tenants" are being referred to? What "One Thing" does UNIX do well?

You've left me with more questions about this book than I would have had otherwise. Please try to do a more thorough review next time.

And, to get on a technicality that will probably cost me this comment as a Troll, Linux IS NOT THE NEW FACE OF UNIX. Most distributions also don't even come close to being something that would compare to a UNIX certified system.

Finally, please excuse my harshness. I just feel you could have done a better, much more descriptive job. Don't take it personally.

Re:Philosophy my arse

[fruey]

Mission statements are wanky, I'll agree with that.

However, in creating 'just a fucking operating system' you do need to have some guiding principles, which become a philosophy. Nothing to do with wanky paragraphs of a few words which cost millions to 'brainstorm'.

Re:I'll take a shot at it

[Chalst]

UNIX = Commercial way of thinking and doing business from a software standpoint, extended to the hardware aspect (by tieing the commercial, closed software to certain hardware). The old way, it is no doubt dying.

Perhaps you have heard of BSD Unix...?

THIS is the book he's talking about ...

[B0mbtruck]

Linux and the UNIX philosophy

Thought i'd let you know ...
B0mbtruck, one base at a time

Re:Good For Geeks-In-Training

[alex_ant]

Linux is a good thing because it allows you to be a part of a small clique that is able to feel superior to everyone else by virtue of your fiddling about with a system that was designed by the programmer, for the programmer rather than by the programmer for the user (Windows) or by the user for the user (Apple). The fact that non-geeks find it very difficult to e.g. burn a CD using the Linux command line is a great source of pride to dejected geeks everywhere who reason that, if they can't be accepted by mainstream society (due to their obvious massive intelligence of course, not their shocking lack of social skills), they can at least construct their own alternate reality in which they are of superior intelligence (even if that "intelligence" translates into nothing more than the ability to control a computer using cryptic textual commands).

Philosophies no longer apply

[Junks Jerzey]

One of the core tenets of UNIX was that you have small, simple tools and you glue them together. But now the popular programming languages under Linux are C++, Python, and Perl, none of which follow this philosophy. And to get to the point where Linux is a true alternative to Windows on the desktop, you have to put a massive X server on top of the kernel, and put a massive window manager and desktop environment on top of that. In the end, "Linux" is not a simple thing (and arguably even the kernel is not simple, but the API is), because you are looking at the combination of X+Qt+KDE, and that pretty much throws all philosophy out the Window. (Yes, I know you can use Blackbox or something else instead, but then don't go arguing that it's a suitable replacement for Windows.)

Have you ever read code from some of the original UNIX team, such as Kernhigan's Software Tools? Wow, can that man write clean and clear code. The original C compiler is similarly concise. But then look at the sources to just about any Open Source project and see that (1) there's a massive amount of code, and (2) it's mostly very ugly. Unfortunately, even though it's illogical, "open source" and "simplicity" aren't as intimately tied together as one would expect.

Re:I'll take a shot at it

[Tragedy4u]

I don't feel that Unix will ever "die" as you state, despite all the Oracle propaganda Linux is the still the new kid on the block in the *nix sector and has a long way to go in terms of enterprise features which commercial UNIX variants have. Not to mention, some business managers only feel safe with a product if they've paid good money for it (the whole you get what you pay for philosophy and having a vendor to point the finger at) I know that sounds odd but its often true as I've worked for a few very large companies that refuse to adopt UNIX because it's free.

There's nothing wrong with using commercial closed business model's, it all depends on your particular situation, you need to use whichever philosophy and technology is best in your situation. Sometimes having something that is open to the world can be a bad thing.

Works too well for its own good...

[Dr. Zowie]

All those little pipeline shell one-liners are inconsequential precisely because the UNIX philosophy works. Some applications (the monolithic ones) don't fit that ideal very well, but many others (all those little one-liners you use, without thinking much about it) do.

If text manipulation and piping didn't work well in UNIX, you'd know about it -- all those tasks would be a real thorn in your side. As it is, you have the right tools, so they're no big deal.

Re:Philosophy my arse

[harrkev]

So Unix has a 'philosophy' then? And I thought it was just a fucking operating system.

Everything that is designed has a philosophy. For example, imaging a bunch of guys standing around trying to design a four-wheeled vehicle. Here are examples of different philosophies:

1) The car should become a part of the driver. Getting into the car should feel like putting on a running shoe.

2) The car should be functional, yet inexpensive.

3) The car should haul lots of stuff.

4) The car should haul.

Each "philosophy" will produce a very different result. *NIX DOES have a very different feel from Windows.

In Windows, everything is centralized. This is why there is a registry -- one place to keep all data. The web browser is also tightly integrated into the core OS.

In Linux, everything is a little piece. If you want to build your own system, you can pick and choose which packages to install. No GUI, no problem. Every program sticks its configuration into separate little text files.

Which is better is a matter of opinion, and both have their strengths and weaknesses. Both Linux and Microsoft have managed to make some rather good operating systems. In fact, I kind of like Windows (at times). All you have to do is get rid of all Microsoft management and lawyers, and you could have a pretty good company. Then, hire some programmers who know something about security, and you could have the perfect desktop OS. Install a *NIX kernel, and you would have something perfect for the server market ;)

Re:Philosophy how???

[lembree]

Ahh, then, you really should read the book.

There really is a philosophy to Unix and Linux,
and you'll find that when the same philosophy's
applied to things other than OS design, it
results in some interesting and elegant ideas.

This book describes the philosophies embodied in
Unix (and largely copied and expanded upon by
Linux) very well, and in such a way as to not
be religious about it. However, it may give
"non-believers" some understanding of how
Unix and Linux folks think, and therefore a
better sense of why the OSs are the way they are,
and hopefully, a respect for them.

So philosophy, ya, I think so. When applied to
OS design, perhaps you can call them design
principles, but I think that this book is able
to abstract it better than that.

Re:I'll take a shot at it

[crazyphilman]

That's NOT what he's talking about.

The "Unix Philosophy" is the philosophy behind Unix-like O/S'es LIKE LINUX. It's a design philosophy, NOT a marketing one, or even an economic one. Vastly oversimplifying,

1. Don't create huge monolithic programs if you can help it. Create small, elegant programs that each do one specific thing well. Use a scripting language to pipe them together, amplifying their usefulness.

2. Because you want to be able to pipe small programs together to aggregate their usefulness, avoid "captive user interfaces", i.e. interactivity. Lean towards writing software that is comfortable running in batch, on a pipe, in a script. Use command line arguments.

3. Don't reinvent the wheel. If there's already a tool that does what you want to do, use it. If you need to extend its functionality, script it with another tool or tools.

4. Lean towards command line programming, because then everything you've got can be scripted, run in crontab, run in batch, etc. The command line is your friend.

5. Everything is a file. This lets you interact with hardware directly, in your software.

6. Store data as flat text whenever possible, so that down the road, if you want to use it with another program, you'll be able to. This also lets you sift through your data using grep and awk.

7. Use text streams whenever you can, for similar reasons to #6. Got a socket? Pass flat text, not binary. Unless you really MUST pass binary.

I've probably left a whole lot out, but this is the basic gist of it. It's why Linux, Unix, and the *BSDs are so much more useful than Windows.

Re:I'll take a shot at it

[qtp]

UNIX = Commercial way of thinking

The UNIX philosophy has nothing to do with commercial vs Free, or closed vs open and has everything to do with design and problem solving. The comercial aspects of UNIX culture were imposed upon UNIX by shareholders and corporations with little or no regard for who had designed the product, whether they had been compensated, or how future maintainance and development would be accomplished. The development of the EMACS editor, the GNU project, and the GPL license were a reaction to these changes in UNIX development. The GPL was not created as an economic "weapon", nor was it created with money in mind at all. It was motivated by a desire to have the source code available to anybody with an idea and the know-how to implement it.

Many posters here seem to be obsessed with money, and it can't be good for thier thinking. Whether they are dogmatic about giving away for free or about charging for every last thought, it betrays an unwillingness to view subjects and viewpoints as other than economically based. I admit that the economics of software development need be considered in any project, but my opinion is that making design decisions based on monetary arguments is putting the cart before the horse and will often result in poorly designed and inferior software.

The UNIX philosophy is not incompatible with the GPL, nor is it incompatible with comercial licensing In fact, the GPL has very little to do wih money in any way whatsoever. In other words, read the book, come back and discuss philosophy when you're prepared.

Re:I'll take a shot at it

[Arandir]

There were two main branches of UNIX. The first was the commercialized AT&T/USL UNIX, which SCO know apparently owns. The other branch of BSD UNIX. From day one this was noncommercial. It was BSD UNIX that made UNIX a success. Without BSD, UNIX would be down and out in the gutter sharing a bottle of Ripple with Multics and cursing its fortunes.

BSD might not be allowed to call itself a "UNIX" today, but the fact remains that it is still UNIX and it is Free Software.

Source for "In The Beginning..."

[bryane]

The text for Neal Stephenson's book "In the Beginning..." can be downloaded here. Haven't read it yet, but when did that stop anyone here :-)

Re:Interesting perspective, but wondering....

[crazyphilman]

In terms of flat files, XML is a great idea. It makes parsing easy, it aids readability, and it can be matched with stylesheets when you want a nice-looking printout of your data. I wouldn't use anything BUT XML for flat files... :)