7 ms·
Basics of the Unix Philosophy
- wendroid 17y ago18. GNU is not Unix
- szhilkin 17y ago+1
- gvb 17y agoSorry, I clicked the arrow next to +1 and downvoted you.
- JoachimSchipper 17y agoCan 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.
- wendroid 17y agoGNU does not follow the Unix Philosophy and BSD can't talk either 'cat came back from Berkeley waving flags' - Rob Pike
- btilly 17y ago"GNU's Not Unix!" is actually what the GNU acronym stands for. To verify go to http://www.gnu.org/ http://www.gnu.org/ and search for that phrase.
- wendroid 17y agoIt's an irony missed on many people.
- s-phi-nl 17y agoThis 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 http://news.ycombinator.com/item?id=1059853
- silentbicycle 17y agoIt isn't even about GNOME and GUIs, but things like this (http://news.ycombinator.com/item?id=1037509 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 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 17y agoThere 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 17y ago> 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.
- deleted 17y ago[deleted]
- wendroid 17y ago
- alrex021 17y ago> 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 17y agoThat'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.
- ajross 17y agoTo 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.
- sophacles 17y agoI'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 :).
- 17y ago
- chanux 17y agoDoes 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 17y agoIn 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 17y agoAnd Python does have multiple ways to do stuff.
- JoachimSchipper 17y agoI 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.
- rbanffy 17y agoI believe having a "basics of our philosophy" document already contradicts that rule. Not to say it's a bad thing.
- ZeroGravitas 17y agoIs 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.
- duairc 17y agoI 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).
- silentbicycle 17y agoMPD (http://musicpd.org 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 17y agoif you like the Unix philosophy you mighty like Pike's the Acme text editor - http://en.wikipedia.org/wiki/Acme_%28text_editor%29 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 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/ http://man.cat-v.org/plan_9/4/
- nailer 17y ago'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 17y agoThere 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 17y agoPerhaps S-Expressions would have been more hacker-y? XML smells of pointy-haired bosses, nowadays.
- thwarted 17y agoThis 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.
- gnosis 17y agoPowershell 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.
- 17y ago
- sid0 17y agoAt 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/1153211 http://interviews.slashdot.org/article.pl?sid=04/10/18/11532... question 8
- silentbicycle 17y agoIt'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.
- sjs 17y agoPike 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.