

Basics of the Unix Philosophy - Arun2009
http://www.faqs.org/docs/artu/ch01s06.html

======
ZeroGravitas
Is anyone aware of an music library/player alternative that follows this
philosophy?

I'm fairly certain a collection of tools for working with various media would
be much better than the iTunes model. It is clearly the worst Apple software
since it tries to fit everything into a one click trojan horse for installing
on Windows and yet the mainstream Linux alternatives all cargo-cult the basic
interface with no obvious signs they understand why all that functionality is
bundled into one program.

~~~
silentbicycle
MPD (<http://musicpd.org>) is pretty good. It's a server that uses a simple
network protocol for control, and thus has several clients and client
libraries. (I particularly like ncmpc.)

Part of the problem is that many people who switched to Linux _to get away
from Windows_ don't understand Unix, and tend to expect (and implement!)
programs that are based on the Windows GUI model. Unfortunately, it's poorly
suited to designing programs in the Unix style. This leads to monolithic GUI
programs that will only work if you're already using GNOME / KDE / etc.,
rather than programs that take advantage of existing the Unix programming
infrastructure. (This seems to be less of a problem in the BSD community.)

It's possible to write a separate GUI interface wrapper for programs whose
primary interface is a command line or C API, but the Windows programming
culture doesn't seem to emphasize keeping them as separate layers the way that
Unix does.

~~~
wendroid
if you like the Unix philosophy you mighty like Pike's the Acme text editor -
<http://en.wikipedia.org/wiki/Acme_%28text_editor%29> (and Plan9 in general).

Many plan9 programs post a file tree which you can manipulate with regular
Unix tools - Acme's are described here - <http://man.cat-v.org/plan_9/4/acme>

for instance, if I name this shell script C

    
    
        #!/bin/rc
        tags=`{cat /mnt/acme/$winid/tag}
        s = `{echo $tags(1) | sed 's/\.c$//'}
        8c $s.c && 8l -o $s $s.8 
    

And middle click on a 'C' in the tag bar (or anywhere in the window) and the
filename ends in .c, it will be compiled and linked for me. The
/mnt/acme/$winid/tag is exported by Acme which provides a file tree to all of
its windows.

Other similarly behaving programs in the distribution (including the windowing
system) are described in <http://man.cat-v.org/plan_9/4/>

~~~
silentbicycle
I've looked at it. I really like acme/wily's general design, but can't stand
the mouse-centric interface. (Same with plan9 overall, actually.) 9p is pretty
cool, though, and I plan on having the 9p protocol as an example file for the
non-blocking server framework I'm building.

I use Emacs, but my ideal editor would mix Emacs's general buffer and mode
extension model with vi-like keybindings, and use Lua as an extension
language. Life is too short to write yet another editor, though.

~~~
gnosis
I'm a vim guy, so this is all hearsay.. but there are supposedly vi
keybindings available for emacs (and emacs keybinds for vim). I know vim has
Lua bindings, and I would be very surprised to hear that emacs didn't.

So look around.. you might find something close to what you're looking for.

~~~
silentbicycle
The extension for vi keybindings in Emacs is called "viper", though I think
there's another. The problem is that, while you can switch to using vi
keybindings for primary editing, every other single package will use
conventional Emacs keybindings.

Thing is, I don't want to add yet another layer on top of either Emacs (!!!)
or vim. Both have waaaaay too much cruft as-is. (nvi isn't as bad.) I think
the buffers-and-modes extension model in Emacs and vi's modal, primarily
single-key interface are good ideas, though, and I don't see any reason why
they couldn't be combined. I've also looked at uemacs, vile, and the like, but
haven't found one that suits me. In the mean time, Emacs is good enough for
me.

------
nailer
'Separating interface from engine' clashes with the shortsighted 'text is the
universal interface' rule.

A great deal of Unix prefers the latter to the former - eg, hunting for a
regex to identify some data rather than being provided with something which
properly separates the data from the presentation.

Object pipelining shells (powershell) and higher level shells (ipython) get
this right.

~~~
thwarted
There was an endeavor to create versions of all the shell utilities that take
and generate XML streams before powershell, but it never caught on and I don't
think it got very far.

~~~
eru
Perhaps S-Expressions would have been more hacker-y? XML smells of pointy-
haired bosses, nowadays.

~~~
thwarted
This was before XML acquired the, ahem, "seriousness" of the rep it now has.
Really, I don't think the exact format mattered, because it would only be used
between the processes themselves, you'd use some kind of formatter on the
output end to produce something actually readable. The transport format isn't
what killed it; one might argue that flat text is good enough, and that's what
killed trying to create an alternative inter-pipe format.

I still think it's a good idea, but even the success of powershell (how often
do you hear of someone actually using it?) says it's not going to go anywhere.

~~~
nailer
It's pretty common these days - most Windows infrastructure folk I work with
check a new product for Powershell support as a purchase condition.

~~~
thwarted
Admittedly, I'm no longer seriously in the market for Windows software (and
haven't been for a long while), so I wasn't even aware that "powershell
support" was a possible selling point. What are some examples of software that
do have powershell support? I could see it making a big difference with some
system management tasks.

------
alrex021
> 17\. Rule of Extensibility: Design for the future, because it will be here
> sooner than you think.

Question is "how much" design for the future is necessary today. The basic
rule of thumb that I follow is to ensure that necessary means of abstraction
have been applied and are in place today so that tomorrow we can extend
without reworking all the parts.

~~~
silentbicycle
That's covered by rules 1-6, which emphasize constructing the system using
small, independent programs communicating over pipes.

I'd rephrase rule 17 as "Don't paint yourself into a corner.". It's easy to
waste time overgeneralizing a program before you have a clear idea how it will
actually be used. The emphasis on prototyping also keeps this in check,
though.

------
chanux
Does Unix Philosophy clash with Python Philosophy?

Unix: Rule of Diversity: Distrust all claims for “one true way”.

Python: There should be one—and preferably only one—obvious way to do it.

Well.. I'm comparing an OS with a programming language.

~~~
TomasSedovic
In that case you can compare Python with Perl ("there's more than one way to
do it").

I don't think they necessarily have to clash -- you may have multiple ways but
one would be obvious in a given situation.

~~~
eru
And Python does have multiple ways to do stuff.

------
sid0
At least the "one tool for one job" part has been pronounced dead by Rob Pike
himself.

[http://interviews.slashdot.org/article.pl?sid=04/10/18/11532...](http://interviews.slashdot.org/article.pl?sid=04/10/18/1153211)
question 8

~~~
silentbicycle
It's worth noting that when you set up a pipeline of processes, each can spawn
on its own core. Setting up task-oriented processes is an idea that still has
a lot of power in it, whether you're talking about the "lots of tiny C
utilities" approach or something more like Erlang.

While Pike doesn't mention it explicitly, I think the issue is that the
context for "one tool per job" shifted from the shell (with Unix itself doing
process management) to the Python runtime, the JVM, etc. This has its
advantages and disadvantages. Working at the level of different processes,
each can be written in its own language and rely on simple interfaces such as
text-streams or structured files for communication. Within other contexts,
everything can work with the same object system, process supervisor
infrastructure, etc.

------
wendroid
18\. GNU is not Unix

~~~
s-phi-nl
This and the post by silentbicycle above [1] make the point that GNOME
abandoned the Unix philosophy to provide a more Windows-style monolithic GUI
program.

[1] <http://news.ycombinator.com/item?id=1059853>

~~~
silentbicycle
It isn't even about GNOME and GUIs, but things like this
(<http://news.ycombinator.com/item?id=1037509>). You don't need to add an
"overwrite in-place" option to sed when you can add it to _everything_ by
making it its own command. Unix design concerns how functionality is factored
at the level between programs, not just between objects in a program.

See "cat -v considered harmful" (<http://gaul.org/files/cat_-
v_considered_harmful.html>). GNU just does bloat _bigger and better_. (Compare
BSD make and GNU make, for starters.)

~~~
philh
There are advantages to having overwrite-in-place as an option. If sed is
passed a malformed expression, or for whatever reason is unable to operate,
the file is untouched. A separate program would clobber it.

Better to have the separate program than everything to implement its own
version, but having both isn't necessarily bad.

~~~
silentbicycle
> A separate program would clobber it.

Nope, you can check the return value from the program(s) run inside of it and
revert to the backup file if there's a problem. You _really_ don't need it to
be handled specifically by sed.

There's actually an example script that does exactly that in _The Unix
Programming Environment_, called 'overwrite', on page 154.

