

The UNIX Way - techdog
http://asserttrue.blogspot.com/2009/08/unix-way.html

======
makecheck
This blog post contains mostly a small list of design principles. But those
ideas are from ESR's book "The Art of UNIX Programming", where they are
expanded upon in great detail, with excellent examples.

I am someone who practices the Unix philosophy on a regular basis, and cringes
when I see how twisted and inelegant Windows has become (even on the
programming side). I consider this book a must-read for people who know only
Windows. It is also an interesting book for those who know Unix already.

~~~
nailer
'Text as the universal interface' clashes quite badly with separating content
from presentation. This means you're forever relying on regex's to rip data
out of other applications, and relying on those other applications not to
change their output.

Compare finding processes starting within the last hour on Unix and Windows:

    
    
        ps | grep 'regex representing the current amount of columns output by ps where start time is less than 2 hours'
    

Windows (ps is an alias for get-process):

    
    
        ps | where COLUMN <= value
    

The latter is much more robust. As Powershell gets more cmdlets it's going to
become increasingly useful. That said, I prefer Unix for other reasons.

~~~
makecheck
True, though "ps" isn't the best example, as it's one of the least portable
commands I've ever seen. :) Its output is not even consistent from one Unix
variant to another.

I kind of hope most Unix variants follow the /proc filesystem model of Linux.
It basically cleans up these kinds of queries considerably.

------
wwalker3
These rules don't seem to apply to the modern age very well. The rules "Avoid
captive user interfaces" and "Make every program a filter" mean that you can't
write a text editor. The rule "Store data in flat text files" means you can't
write a (reasonable) MP3 player or video editing program.

"Build a prototype as soon as possible" is pretty general, but most of these
rules are just good guidelines for writing command shells and compilers -- not
coincidentally, two of the main concerns of early Unix developers.

~~~
SwellJoe
s/rule/guideline/ and maybe you'll be able to see the forest past the trees.

 _The rules "Avoid captive user interfaces" and "Make every program a filter"
mean that you can't write a text editor._

Not true. Some text editors are of the UNIX nature, and some are not.

But, the fact is that you probably _shouldn't_ be writing a text editor today.
Editing text is a solved problem, and you'll almost certainly do it worse than
emacs or vim if you try.

 _The rule "Store data in flat text files" means you can't write a
(reasonable) MP3 player or video editing program._

Sure you can. Your playlists can be flat text. Your video queue list can be
flat text. Your preferences can be flat text. MP3s and video can also be
processed in a filter style (and often are conceptually so within the UI).
Only problem is compressed data isn't in a form that can be filtered without
first decompressing it. But, I regularly batch process music and audio files.
If I did a lot of video work, I'm sure I'd also do the same with video.

Your program can certainly be a filter for those types of files. Sox, lame,
and the ImageMagick convert utility are good examples of media programs that
embrace the UNIX philosophy.

The point is that you shouldn't use a database if you don't need the things
that databases provide beyond storage of blobs of data. Don't over-architect
your file formats, don't obfuscate them, don't make it harder for users to use
your code in ways you didn't envision. This is the UNIX philosophy...not that
you aren't allowed to operate on non-text data.

Programs have been working with messy real world problems since before UNIX
and the UNIX philosophy existed. The need to interact with non-text data
hasn't sprung into existence in the past ten years. Before there were MP3 and
video, there was typesetting, and scientific data analysis, and moon landing
calculations, and neural networks, and telephone switching, and so on and so
forth.

Programming in the UNIX philosophy is always possible, and, as far as I can
see from my many years of software development, always wise.

 _but most of these rules are just good guidelines for writing command shells
and compilers -- not coincidentally, two of the main concerns of early Unix
developers_

Every single problem of note that I can think of would be well-served by
breaking it into reusable pieces. Sometimes this just means libraries, rather
than small standalone programs, particularly on the desktop...but sometimes
separate programs that happen to be used by a "main" program are the right way
to go. Things like video and audio compression can be, and often are,
performed by separate programs.

This separation is a win on many levels...on a multi-core machine, the new
process can have its own resources, while you continue to work away on your
media. It can be upgraded or maintained at a specific version more readily. It
can be used by other programs or in a batch mode from a script or batch
compression utility.

I think it takes someone who doesn't use UNIX on a regular basis (actually
uses UNIX; not merely a GUI shell on top) to think these concepts are outdated
and not generally applicable.

~~~
wwalker3
I like many of these principles, it's just hard to apply more than a few of
them to a given program.

Vim and emacs have captive user interfaces. MP3 encoders like LAME write
binary data files. That doesn't mean they're bad programs, but it does make
the principles tricky to apply, since they seem to be useful in some cases but
not others.

I'm on the Linux command line all day at work, without any sort of GUI
frontend. It's got its strengths and weaknesses, just like anything else.

~~~
SwellJoe
_Vim and emacs have captive user interfaces._

With many well-placed escape routes. Again, think of them as guidelines, not
hard unbreakable rules. The overarching gestalt is to make tools that can be
used by other tools. vim and emacs happen to be the user of other tools
(acting as a shell) most of the time, but they can also be used as tools by
other programs (mutt opens your editor of choice for composing messages, for
instance). They also use all flat text for their configuration and scripting.

 _MP3 encoders like LAME write binary data files._

So? That's their job. Their configuration is done from the command line and
via flat text. They are filters.

Again, the "flat text files" rule is not that you're not _allowed_ to work on
non-text data (that would be stupid; a lot of real world data, maybe most of
it, is not representable as plain text). It's that when you have the option,
you choose flat text, because it is easier to work with from other programs
than yet another custom database or file format. Tools using tools is the UNIX
philosophy. LAME is used by hundreds or thousands of other tools. It is
_definitely_ of the UNIX nature and one of the more successful examples of it.

You're viewing things as some kind of dogma. That's not UNIX-y. Solving
problems is UNIX-y, and there are some good rules of thumb that have been
developed over the past 30+ years for solving problems in ways that stand the
test of time. The fact that grep, sed, and so on, are used more today than 30
years ago is a testament to the strength of those ideas. Just because some
folks ignore that wisdom doesn't make it invalid.

------
leif
Too much of desktop linux has strayed from his #5, and it bothers me to no end
(yes this means you, hal and dbus and gconf).

~~~
nailer
GConf is just text files. Open your .gconf folder.

~~~
leif
Just xml files in a horribly tall folder hierarchy, you mean. Hand-editing xml
(especially with a foreign schema) is retarded.

------
drhowarddrfine
It amazes me that The Way of Unix is not known and understood, and most
certainly applied, by everyone everywhere.

~~~
weaksauce
If you amend that statement to "..., and most certainly applied, by everyone
where it makes sense." I would be 100% on board. Engineering a solution is all
about tradeoffs and sometimes the tradeoff needs to break a long standing
convention to be fast enough / have a cohesive UI / whatever. I love the UNIX
way but it is not the solution for Life, the Universe, and Everything either.
That is 42.

