Basics of the Unix Philosophy | Hacker News Reader

Basics of the Unix Philosophy

faqs.org

78 pointsArun200949 comments

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.

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.

mpd is what I'm using, since ditching Amarok (hate 2.0 and 1.4 is dead to me now that gentoo's switched from KDE 3 to 4)...

But mpd has one crushing flaw: no ratings! I don't know how people live without them.

I'm hoping sometime soon xmms2 will become stable enough to be useful, as it's supposed to have some sort of ratings support, and is build around the same kind of philosophy that mpd and Unix have.

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/

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.

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.

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.

I use Quod Libet, which is a great program for listening to and browsing your music collection. It also comes with Ex Falso, which is a separate program that's great for organising your music collection. If I'm ever putting music onto an iPod, I use gtkpod... it's just a pity that it's such an unstable program (gtkpod).

Music Player Daemon (http://musicpd.org) would be one example.

It operates as a OS daemon -- therefore without any UI per se. It is controlled it using a text-based protocol over TCP/IP.

Usually, the user controls it via UI frontend that can be graphical, text-based or what have you. And you can have as many of those as you like (for instance one for xwindow, another for command line, third that shows you what is currently being played, fourth for album art and lyrics...)

I use mpg123 (http://www.mpg123.de/), a command-line player. There's also mpg321, but I haven't used it much, and apparently there's an ogg123 player as well.

mpg321 is for platforms with no floating point processor.

I use Decibel Audio Player (http://decibel.silent-blade.org/). All it does is play music, and it does that pretty well.

If you're looking for a simple GUI audio player, I recommend it, although I'm not really sure how closely it follows this philosophy.

It doesn't seem to. EDIT: Apparently it has a separate command-line interface (which isn't mentioned on the page). It just looked like YA GNOME media player.

One quick test is if you can see another program using it directly. The reason Unix programs typically have such an austere interface is because it makes it easier to use them from another program (which may be a nice interface).

There seem to be parallel ideas in RESTful web design.

It can be used by another program directly though--it has a command-line interface (decibel-audio-player-remote) that can do remote control, and it can output information about its current status to a text file. (It's not as good as most Unix programs, but it's a lot better than nothing.)

It's not command-line only like most Unix programs, and it's certainly not as simple as most Unix programs, but I do think it does incorporate some of the tenets of Unix philosophy (most importantly: doing one thing and doing it well).

I realize that there's other music playing software that may conform to Unix philosophy more rigidly, but in my experience good back-ends don't necessarily translate to good GUIs, and a GUI is what I want for my media player. I think Decibel is a good compromise.

'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.

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.

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

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.

Powershell seems to go against the whole "Windows philosophy" (ie. monolithic, inscruitable, and dumbed-down).

More seriously, I have no doubt that many Windows admins are using it, but it's not likely too many typical Windows users even know what it is.

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

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.

Well, none of these are hard and fast rules, just rules of thumb that let you work with Unix's strengths. For example, if you store your data in config files, you can keep them in git (or whatever), and neither has to know anything about the other. Text isn't the universal interface, it's just a simple one.

You wouldn't stream video data as text, but that's because there are other major factors that make doing so an unreasonable trade-off.

> 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.

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.

To advocate for the devil: how many useless (or at least unused) abstractions has this produced in your code? How many interfaces have only a single subtype (or turn out not to need runtime virtualization at all)? How many dead/untested accessor methods are there? How many declared methods went unimplemented because they weren't called? How many "plugin" interfaces have you written for software that doesn't need runtime plugins?

It's been my experience that "future proof" code tends to be filled with this stuff, and that the cost of all this chaff is vastly higher than the authors think it is when they write it.

I've always found that if I can forsee an obvious feature or set of functionality that could be useful, to go ahead and either just implement it, or make my low-level functions capable of supporting that from the get-go. Doubly so if the difference in effort is a day or less. I sometimes call this the miracle worker principle. Some bosses dislike you doing things beyond what they say, so you can't tell them when you are following this principle. In 6 months, when they get around to "coming up with the next great idea", you can flip the metaphorical switch, and have their functionality in mere moments. You look like a miracle worker :).

Yeah I wondered about that one. I would have said it was more like "design for now, tomorrow is a long way off".

I think perhaps it means more like "don't make your Epoch 32bits long, it'll soon be 2038" oh

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.

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.

And Python does have multiple ways to do stuff.

I don't think those clash; the Unix philosophy is not about single lines of code or even a single "paragraph" of code, but about overall design.

I believe having a "basics of our philosophy" document already contradicts that rule.

Not to say it's a bad thing.

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... question 8

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.

Pike says that Perl delivered the eulogy for "do one thing, do it well" but perhaps the scope of those things has just increased. Especially since there are so many viable scripting languages today it's more important than ever to create interoperable tools that can be plugged together, for code reuse sake. I think it's great that I can shell out to markdown.pl from a Python or Ruby program rather than rewriting it in the language I happen to be using that day.

Let's not throw the baby out with the bath water. Code reuse is good, and so is doing things well.

18. GNU is not Unix

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

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.)

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.

> 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.

After the introduction of Windows 95, it was clear that the free software universe was lacking a number of technologies and that we were lagging behind in various areas.

At Microsoft I learned the truth about ActiveX and COM and I got very interested in it inmediately [sic]. Upon my return to Mexico Federico and I started to design a GUI control infrastructure for Unix that we code named `GNOME'.

"The Story of the GNOME project" http://primates.ximian.com/~miguel/gnome-history.html

or "How one man ruined everything"

"In a world of small programs that did one thing well and communicated via text-based protocols... One man sought to challenge the system."

Unix is simple. It just takes a genius to understand its simplicity. - Dennis Ritchie

The X server has to be the biggest program I've ever seen that doesn't do anything for you. - ken

Can you explain what you mean by that?

The BSD user in me completely agrees; I'd just like to know if that's what you intended.

"GNU's Not Unix!" is actually what the GNU acronym stands for. To verify go to http://www.gnu.org/ and search for that phrase.