15 ms·

The Rule of Silence (2006)

338 points by riansanderson 10y ago

ghshephard 10y ago
I appreciate the overall message the article is trying to communicate "Silence is golden, in many contexts for many reasons - be considerate before you make noise", but, as an aside, the third reason, "command line programs", should include the a reference to stderr keeping things out of view of your pipe and doing a good job of making sure you don't clutter your command pipes.
cyborgx7 10y ago
This is a part of the unix philosphy I often forget, but agree with just as much as the rest. As an example: I love curl for piping the data to stdout per default, but I'm frequently annoyed by the progress bars I didn't ask for, especially if a script involves multiple curl commands.
- bluetomcat 10y ago
  Modern Unix tools like curl are like swiss-army knives with regard to the numerous combinations of options that they accept. A particular combination of options may change the behaviour of the program in a way that it still succeeds, but does something slightly differently.
- pwdisswordfish 10y ago
  Seconded. Though curl isn't the worst offender in that regard. Anything that touches TeX drives me nuts with its blatant disregard for this rule. Not only does every TeX engine spew pages of output while processing even the simplest documents, but there is no way to turn it off. (It's hardly the only way in which TeX makes my blood boil, but it's the most visible one.) FFmpeg is also quite bad here, but at least you can use -hide_banner and/or -loglevel to alias the problem away and mostly forget about it.
  - hawski 10y ago
    One of the things I liked about typesetting with troff is that it follows Unix conventions (duh).
  - tomsmeding 10y ago
    Combined with the fact that they also spew out a number of files that you don't want, because it isn't capable of traversing the source more than once.
dom0 10y ago
"Rule of Silence" sounds so dark. Nope, I'll stick with "no news is good news".
- pantalaimon 10y ago
  I think it fits well into the whole monastery style type of UNIX philosophy.
xg15 10y ago
Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) I think the rule makes sense within the specific constraints *nix programs are usually expected to work in (two output channels with no structure except the one informally defined by the program and the convention that the output should be human- and machine-readable at the same time) but I don't see it as a general rule if better ways to filter the output are available.
- dom0 10y ago
  > Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) $ man foo *scroll to the end with the EXAMPLES section* There should be an option for that. man --take-me-to-the-examples foo
  - vog 10y ago
    (NOTE: The parent comment was edited. This response applies to the original parent comment that contained just the command line ("man foo" + EXAMPLE section) and nothing else.) Wow, I haven't seen such a blunt and unhelpful RFTM comment for a while. This comment is inappropriate in so many ways: 1) The unix systems have an inconsistent documentation mix of man pages, info pages, "-h", "-help", "--help", HTML docs, separate manuals (e.g. Debian Administrator's Handbook) and so on. 2) "man foo" leads to: "No manual entry for foo" 3) "man vi", as well as "man vim" both lead to a manpage that has no EXAMPLES section at all (see https://www.freebsd.org/cgi/man.cgi?query=vi https://www.freebsd.org/cgi/man.cgi?query=vi, https://www.freebsd.org/cgi/man.cgi?query=vim https://www.freebsd.org/cgi/man.cgi?query=vim) 4) The Vi(m) manpages explain only the command line arguments, not the editor commands. The latter are available by typing ":help" in the editor.
    - swiley 10y ago
      You don't really need an "examples" section for vim, 90% of the time you just type "vim file" which the usage info probably covers well enough. You only need an "examples" section for something like zip.
zeveb 10y ago
Honestly, I don't know if the rule of silence is actually all that good of an idea. Unix already gives us stdout vs stderr; it's one thing not to write useless information to stdout, but it could be useful to have a stdinfo or stdlog or what-have-you. Granted, with too many options it could quickly get confusing (should this message go to stdout or stdinfo; is that message more informational or more debugging?), but I think that it could be managed. Similarly, I think that Unix fell down by relying too much on unstructured text (in the sense that the structure isn't enforced, not in the sense that it's altogether absent): because of this, every single tool rolls its own format, and even very similar formats may have subtle incompatibilities. I'd love to see a successor OS which builds on the lessons of Unix, Plan 9 and other conceptually brilliant OSes, but I fear the world will never see another successful operating system.
- cyborgx7 10y ago
  If looking at the history of tech, but als the general history of humanity, has taught me anything, it's that assuming the current systems will never fall and be replaced will always end up making you look like a fool eventually.
  - stevedonovan 10y ago
    To paraphrase Keynes, in the long run we are all fools. (Except for Alan Kay, apparently)
- bluetomcat 10y ago
  > Similarly, I think that Unix fell down by relying too much on unstructured text This is what made Unix last. Text and keyboards are the universal computing interface that has survived since the 1970s.
  - zeveb 10y ago
    Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall-not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s. There's no particular reason why /etc/passwd couldn't be: ((root nil 0 0 root /root /bin/bash) (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …) There are any number of similar dialects which could be used, of course, but the principle is obvious.
fimdomeio 10y ago
Can help falling in love with the irony that most smartphones have an underlying unix version with mostly an oposite philosophy
- withholding 10y ago
  No irony there.
bendbro 10y ago
This page looks very nice
peterfisher 10y ago
don't forget about the "rule of repair" :p
amelius 10y ago
Unfortunately, in too many cases, a lot of Unix network tools also abide by the Rule of Silence when they should be giving meaningful error messages instead.
vacri 10y ago
Similar to this rule is POLA - the Principle of Least Astonishment. The idea is that if you ask a tool to do something, it should generally do just that and nothing else. If you were to run a tool without args or config, then it shouldn't do something unexpected. Even if nothing else, this rule/principle/whatever is my favourite by name :) https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
grabcocque 10y ago
May as well be called the rule of gratuitously hostile user experience.
- pif 10y ago
  It's clear you don't know what you are talking about. - Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with.
bjourne 10y ago
It's often a stupid rule. If you have a process that is stuck, you type "kill <pid>" to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps <pid>" to see if it is still alive. If it is, you try again with "kill -9 <pid>". I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds and then print if the process is still alive or not. Edit: those who are saying that I can write a wrapper script is missing the point. The point of computers is to be useful to their users, not to follow some philosophy people invented almost 50 years ago. Like if someone is bothered by kill showing messages, they can write a wrapper script (kill > /dev/null how hard is that?) or beg the developers to add a -q option to kill (like grep has) or write a new tool for sending signals. Also, the program is called KILL so one could be forgiven for assuming it's main purpose is to KILL things...
- anoother 10y ago
  I don't find this stupid. The job of `kill` is to send a signal, not to wait around afterwards. Unix makes it trivial to write a wrapper script around `kill` that does exactly what you want -- that's the entire point.
  - verinus 10y ago
    then it should be named `sendKill` imho...
    - teddyh 10y ago
      Given the naming conventions of early Unix, you should be happy they didn’t name it “kl”.
- deleted 10y ago
  [deleted]
- adrianN 10y ago
  If you want that behaviour it is trivial to write a wrapper script that does this. If you don't want that behaviour, getting rid of it if it were built-in would be more difficult.
renox 10y ago
As with any rule it has good and bad consequences: * good: easy to parse the result, easy to chain. * bad: no progress report, annoying with long duration commands.
- grive 10y ago
  If your command is ongoing, you can argue that the time it is taking is in itself surprising. You expect it to finish at any time. It continuing is the surprise. A marker for its progression is thus, IMO well within the range of respecting this philosophy.
- dangravell 10y ago
  As per the article: --verbose
martijn_himself 10y ago
I wish people would live by this rule more often.
- kagamine 10y ago
  User kagamine is reading your comment. User kagamine has read you comment. User kagamine has processed your comment. User kamamine came up with a barely witty response. User kagamine has included the barely witty response for your amusement and irritation. User kagamine hopes to not be banned for this trivial response. Follow me on TwitFace for more like this and pictures of food. This is the world we live in, the Rule of Silence seems like a unique and valuable asset to Unix in this day and age.
- taneq 10y ago
  Have you ever tried to talk to a person who gives absolutely no nonverbal cues as to whether or not they're listening to you? It's infuriating. Acks are important.
  - athenot 10y ago
    Yes I have. It's very common in some Eastern European countries, where the words stand on their own without embellishment. Jokes come with no intonation-based warnings. Similarily, listening is presumed and doesn't come with colorful Southern European–style cues. It's not infuriating, it's just different.
    - taneq 10y ago
      What's infuriating is when seven times out of ten, you eventually say "hey are you listening?" and they respond that of course they're listening, whyever wouldn't you think so? And the other three times out of ten they're actually not listening and they haven't heard a word you've said for the past few minutes, and you have to either repeat yourself or just stop trying to talk to the person.
return0 10y ago
It's not some specific "rule of science" , it's basically occam's razor
kbart 10y ago
Having debugged Linux kernel and userspace programs extensively, I'd say this rule is golden. Typical user don't need logs, unless something is really f*cked up. On the other hand, if you are running production or development machine, you can enable as many log messages as you want as most of it can be turned on via /proc/sys/kernel/printk (kernel messages), program parameters or writing your own specific messages in code if that's not enough. Actually, I more often encounter the opposite problem -- there are so many log messages, that it's hard to find a specific problem among them.
- vog 10y ago
  > there are so many log messages, that it's hard to find a specific problem among them. This is exactly my experience, too. Some programs get this even worse: They spam you with lots of useless information, yet when something goes wrong, you don't get the information you need. Instead, you have to rerun it to increase the verbosity even more. So ... if I have to rerun and having a hard time trying to reproduce the issue anyway, why did it spam me in the first place?
throw2016 10y ago
I think using the word 'philosophy' is like antimarketing. People have a kneejerk reaction to the word as something unchanging and stuck in the past and it lends itself easily to negative connotations. Take an example. Build small components that can be reused. Its like SOA way before SOA came into use and makes perfect sense. Now criticizing that is much more difficult and will require technical depth than just dimissive comments about 'unix philosophy'. In this case this is the first I've heard of a 'philosophy' of silence and it is often not golden. From a technical perspective its important for users to get feedback and not generic unhelpful error messages or commands disappearing. Fortunately on Linux logging is usually quite good and most experienced users can pinpoint errors quite quickly but options like -v, --v, -vv, -vvv far from helping often increase technical load.
dangravell 10y ago
The Unix philosophy of small, modular processes feels right to me, as a user and a coder. However the business and product developer in me wonders how I apply this to building more complex systems. Normally this involves building multiple functionalities. Does the philosophy say I shouldn't build "systems" that are complex and do multiple things? Or does it talk about how these should be implemented, as co-operating processes?
- edblarney 10y ago
  The 'do one small thing and do it well' philosophy is at least contentious in the general sense. Reality: no unit exists outside the context of it's ecosystem. Ergo, the API to that unit, and the degree to which it integrates with the other pieces is paramount. The 'do one thing and do it well' ideal implies almost a kind of 'unit sovereignty' that in many cases does not exist. In large, complex systems, 'units' can only view as parts of a greater whole. 'What they do' is almost less important than 'how well they fit'.
mojuba 10y ago
I always liked how MacOS loads silently without annoying the user even when it does some "hard" stuff like fsck. Generally I think engineers need to fight the temptation to show off the importance and complexity of their software by spitting out all the unnecessary details and logs.
- michrassena 10y ago
  I generally like how Windows and OSX both load silently when things go right too. Text on a black screen, to your standard computer user, looks like an error at worst and just a bunch of junk at best. Most Linux systems I've used, and I know when talking about Linux distributions someone can always find an exception, print a bunch of stuff when they start up.
- kosma 10y ago
  One way to completely break a Mac user out of their comfort zone is to switch the machine into verbose boot mode (sudo nvram boot-args=-v). Makes it look like old Slackware.
- flukus 10y ago
  Don't all of the "user firendly" linux distros do this too?
pdkl95 10y ago
> There is no single, standardized statement of the Unix philosophy They could at least link to tAoUP[1]. [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html
augustk 10y ago
One consequence of "the rule of silence" is that sometimes it is not obvious if a command is processing data or waiting for input, there is no visual difference.
- pwdisswordfish 10y ago
  You can often just check by hitting ^D, but yes, this is a workaround, not a fix.
- ddalex 10y ago
  This is why well-behaved programs prompt for input. Like bash, e.g.
  - bluetomcat 10y ago
    With cat being the notable exception :-)
    - marcosdumay 10y ago
      And grep. Programs that use the input and output to carry data around can not show prompts to the user.
      - athenot 10y ago
        A workaround is to prompt on STDERR. Data input will enter the same place, and output will be distinguished from the text for prompts.
- laumars 10y ago
  That's more an occasional annoyance than a real problem though. The only commands that don't prompt when waiting for input are commands that are written specifically for stream processing from stdin. In which case the user should already be aware of it's behaviour because they're either already familiar with the command or have have consulted it's man page (or similar reference) before executing it. So the unprompted waiting for using input is a bug in a shell script / command line pipe and thus usually pretty quick to debug. Going back to the man page point: I will granted you that not everyone does check what a program does before running it. Sadly in those instances there's little you can do to protect them from themselves. It's similar to how you cannot protect people from blindly copying and pasting code from the internet. If someone is willing to run a command "blind" then the usefulness of the output is the least of their worries.
mvindahl 10y ago
[ ... ]
kozak 10y ago
Simplicity is always a virtue.
borplk 10y ago
To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other exotic ways of dealing with the problem. Oh you don't like that output? Easy! pipe that crap into sed then awk then perl then cut then wc and you're golden! When you get tot that point you have to understand that you have chosen to ignore the fact that the data you are dealing with must be represented in something much closer to a relational database than lines of ASCII text. Logging is another area you see the consequences of this. A log is not a line of text. Repeat after me a log entry is not a damn line of text. "Oh but isn't it neat you can pipe it to grep?" NO! No it's not neat, maybe it was neat 20 years ago. Today I want that damn data in a structure. Then you can still print it out in one line and pipe it to grep all you want. Another area that you see the unfortunate side effects of this philosophy is with the mess of file-based software configuration. Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted. I want my software configuration stored in a database not in a bunch of fragile files with made up syntax that are always one typo or syntax error away from being potentially silently ignored. The fetish for easily-editable ASCII files and escaping from structure is holding us back. Structured data does not automatically imply hidden and inaccessible, that's a matter of developing appropriate tooling.
- skrebbel 10y ago
  In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware of the downsides of this philosophy. If not, try configuring IIS.
  - rtpg 10y ago
    Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many versions of " get file created timestamp from ls" do we need? Something Windows does get right is the clipboard. You place a thing on the clipboard, and when you paste, the receiving program can decide on the best representation. This is why copy-pasting images has worked so magically. I could see an alternative system where such a mechanism exists for shell programs.
teddyh 10y ago
See also the following relevant chapters of The Art of Unix Programming: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450 http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id... http://www.catb.org/~esr/writings/taoup/html/ch11s09.html http://www.catb.org/~esr/writings/taoup/html/ch11s09.html
pgt 10y ago
Spolsky addressed this cultural difference between the Windows and Unix world in 2003: https://www.joelonsoftware.com/2003/12/14/biculturalism/ https://www.joelonsoftware.com/2003/12/14/biculturalism/ At its core, it is about putting humans before computers. Engelbart coined HCI as Human Computer Interface, not CHI. This philosophy steered my product designs ever since I read that as a teenager.
digi_owl 10y ago
I love this rule, as it is the opposite of what modern computing does. When i plug something into a Windows PC i get a multitude of beeps and popups saying it did everything right. But if something goes wrong there is a eerie silence and i have to dig into the error hex dumps to hope i find anything useful at all (or just reboot and hope it works right on second try).
stratigos 10y ago
love this article. the past paragraph is great - i often claim that stores do their best to drive me away by playing horrible music and making sure i am as annoyed as possible with no hope of being able to focus on purchasing something.
kulu2002 10y ago
I think this article gives good perspective regarding User Exp of system. Windows is made for much wider audience whereas UNIX is used by skilled people. I think its inappropriate to compare both philosophies with regards to this article.
emodendroket 10y ago
I wish I could find that old thing about ordering a burger at the Unix restaurant, where the clerk keeps giving you cryptic responses when you order wrong and then, when you do successfully order, says nothing, leaving you wondering whether your order has been accepted or not.
- enigmango 10y ago
  Probably this: http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.html http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.h... I hadn't heard of it until now. Thanks for the good read!
  - emodendroket 10y ago
    That's the one.
kkotak 10y ago
It is refreshing to see no author name attributed to the text.
Edward16 10y ago
You need a savvy hacker,one who specializes in Expunging Criminal Records and Change of University Grades. Contact edwardsnowcare@gmail.com One who would be able to carry out and successfully execute hacks on your behalf while keeping it all discrete and under the radar.

338 points by riansanderson 10y ago

I appreciate the overall message the article is trying to communicate "Silence is golden, in many contexts for many reasons - be considerate before you make noise", but, as an aside, the third reason, "command line programs", should include the a reference to stderr keeping things out of view of your pipe and doing a good job of making sure you don't clutter your command pipes.

cyborgx7 10y ago

This is a part of the unix philosphy I often forget, but agree with just as much as the rest. As an example: I love curl for piping the data to stdout per default, but I'm frequently annoyed by the progress bars I didn't ask for, especially if a script involves multiple curl commands.

bluetomcat 10y ago
Modern Unix tools like curl are like swiss-army knives with regard to the numerous combinations of options that they accept. A particular combination of options may change the behaviour of the program in a way that it still succeeds, but does something slightly differently.
pwdisswordfish 10y ago
Seconded. Though curl isn't the worst offender in that regard. Anything that touches TeX drives me nuts with its blatant disregard for this rule. Not only does every TeX engine spew pages of output while processing even the simplest documents, but there is no way to turn it off. (It's hardly the only way in which TeX makes my blood boil, but it's the most visible one.) FFmpeg is also quite bad here, but at least you can use -hide_banner and/or -loglevel to alias the problem away and mostly forget about it.
- hawski 10y ago
  One of the things I liked about typesetting with troff is that it follows Unix conventions (duh).
- tomsmeding 10y ago
  Combined with the fact that they also spew out a number of files that you don't want, because it isn't capable of traversing the source more than once.

dom0 10y ago

"Rule of Silence" sounds so dark. Nope, I'll stick with "no news is good news".

pantalaimon 10y ago
I think it fits well into the whole monastery style type of UNIX philosophy.

xg15 10y ago

Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) I think the rule makes sense within the specific constraints *nix programs are usually expected to work in (two output channels with no structure except the one informally defined by the program and the convention that the output should be human- and machine-readable at the same time) but I don't see it as a general rule if better ways to filter the output are available.

dom0 10y ago
> Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) $ man foo *scroll to the end with the EXAMPLES section* There should be an option for that. man --take-me-to-the-examples foo
- vog 10y ago
  (NOTE: The parent comment was edited. This response applies to the original parent comment that contained just the command line ("man foo" + EXAMPLE section) and nothing else.) Wow, I haven't seen such a blunt and unhelpful RFTM comment for a while. This comment is inappropriate in so many ways: 1) The unix systems have an inconsistent documentation mix of man pages, info pages, "-h", "-help", "--help", HTML docs, separate manuals (e.g. Debian Administrator's Handbook) and so on. 2) "man foo" leads to: "No manual entry for foo" 3) "man vi", as well as "man vim" both lead to a manpage that has no EXAMPLES section at all (see https://www.freebsd.org/cgi/man.cgi?query=vi https://www.freebsd.org/cgi/man.cgi?query=vi, https://www.freebsd.org/cgi/man.cgi?query=vim https://www.freebsd.org/cgi/man.cgi?query=vim) 4) The Vi(m) manpages explain only the command line arguments, not the editor commands. The latter are available by typing ":help" in the editor.
  - swiley 10y ago
    You don't really need an "examples" section for vim, 90% of the time you just type "vim file" which the usage info probably covers well enough. You only need an "examples" section for something like zip.

zeveb 10y ago

Honestly, I don't know if the rule of silence is actually all that good of an idea. Unix already gives us stdout vs stderr; it's one thing not to write useless information to stdout, but it could be useful to have a stdinfo or stdlog or what-have-you. Granted, with too many options it could quickly get confusing (should this message go to stdout or stdinfo; is that message more informational or more debugging?), but I think that it could be managed. Similarly, I think that Unix fell down by relying too much on unstructured text (in the sense that the structure isn't enforced, not in the sense that it's altogether absent): because of this, every single tool rolls its own format, and even very similar formats may have subtle incompatibilities. I'd love to see a successor OS which builds on the lessons of Unix, Plan 9 and other conceptually brilliant OSes, but I fear the world will never see another successful operating system.

cyborgx7 10y ago
If looking at the history of tech, but als the general history of humanity, has taught me anything, it's that assuming the current systems will never fall and be replaced will always end up making you look like a fool eventually.
- stevedonovan 10y ago
  To paraphrase Keynes, in the long run we are all fools. (Except for Alan Kay, apparently)
bluetomcat 10y ago
> Similarly, I think that Unix fell down by relying too much on unstructured text This is what made Unix last. Text and keyboards are the universal computing interface that has survived since the 1970s.
- zeveb 10y ago
  Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall-not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s. There's no particular reason why /etc/passwd couldn't be: ((root nil 0 0 root /root /bin/bash) (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …) There are any number of similar dialects which could be used, of course, but the principle is obvious.

fimdomeio 10y ago

Can help falling in love with the irony that most smartphones have an underlying unix version with mostly an oposite philosophy

withholding 10y ago
No irony there.

bendbro 10y ago

This page looks very nice

peterfisher 10y ago

don't forget about the "rule of repair" :p

amelius 10y ago

Unfortunately, in too many cases, a lot of Unix network tools also abide by the Rule of Silence when they should be giving meaningful error messages instead.

vacri 10y ago

Similar to this rule is POLA - the Principle of Least Astonishment. The idea is that if you ask a tool to do something, it should generally do just that and nothing else. If you were to run a tool without args or config, then it shouldn't do something unexpected. Even if nothing else, this rule/principle/whatever is my favourite by name :) https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

grabcocque 10y ago

May as well be called the rule of gratuitously hostile user experience.

pif 10y ago
It's clear you don't know what you are talking about. - Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with.

bjourne 10y ago

It's often a stupid rule. If you have a process that is stuck, you type "kill <pid>" to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps <pid>" to see if it is still alive. If it is, you try again with "kill -9 <pid>". I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds and then print if the process is still alive or not. Edit: those who are saying that I can write a wrapper script is missing the point. The point of computers is to be useful to their users, not to follow some philosophy people invented almost 50 years ago. Like if someone is bothered by kill showing messages, they can write a wrapper script (kill > /dev/null how hard is that?) or beg the developers to add a -q option to kill (like grep has) or write a new tool for sending signals. Also, the program is called KILL so one could be forgiven for assuming it's main purpose is to KILL things...

anoother 10y ago
I don't find this stupid. The job of `kill` is to send a signal, not to wait around afterwards. Unix makes it trivial to write a wrapper script around `kill` that does exactly what you want -- that's the entire point.
- verinus 10y ago
  then it should be named `sendKill` imho...
  - teddyh 10y ago
    Given the naming conventions of early Unix, you should be happy they didn’t name it “kl”.
deleted 10y ago
[deleted]
adrianN 10y ago
If you want that behaviour it is trivial to write a wrapper script that does this. If you don't want that behaviour, getting rid of it if it were built-in would be more difficult.

renox 10y ago

As with any rule it has good and bad consequences: * good: easy to parse the result, easy to chain. * bad: no progress report, annoying with long duration commands.

grive 10y ago
If your command is ongoing, you can argue that the time it is taking is in itself surprising. You expect it to finish at any time. It continuing is the surprise. A marker for its progression is thus, IMO well within the range of respecting this philosophy.
dangravell 10y ago
As per the article: --verbose

martijn_himself 10y ago

I wish people would live by this rule more often.

kagamine 10y ago
User kagamine is reading your comment. User kagamine has read you comment. User kagamine has processed your comment. User kamamine came up with a barely witty response. User kagamine has included the barely witty response for your amusement and irritation. User kagamine hopes to not be banned for this trivial response. Follow me on TwitFace for more like this and pictures of food. This is the world we live in, the Rule of Silence seems like a unique and valuable asset to Unix in this day and age.
taneq 10y ago
Have you ever tried to talk to a person who gives absolutely no nonverbal cues as to whether or not they're listening to you? It's infuriating. Acks are important.
- athenot 10y ago
  Yes I have. It's very common in some Eastern European countries, where the words stand on their own without embellishment. Jokes come with no intonation-based warnings. Similarily, listening is presumed and doesn't come with colorful Southern European–style cues. It's not infuriating, it's just different.
  - taneq 10y ago
    What's infuriating is when seven times out of ten, you eventually say "hey are you listening?" and they respond that of course they're listening, whyever wouldn't you think so? And the other three times out of ten they're actually not listening and they haven't heard a word you've said for the past few minutes, and you have to either repeat yourself or just stop trying to talk to the person.

return0 10y ago

It's not some specific "rule of science" , it's basically occam's razor

kbart 10y ago

Having debugged Linux kernel and userspace programs extensively, I'd say this rule is golden. Typical user don't need logs, unless something is really f*cked up. On the other hand, if you are running production or development machine, you can enable as many log messages as you want as most of it can be turned on via /proc/sys/kernel/printk (kernel messages), program parameters or writing your own specific messages in code if that's not enough. Actually, I more often encounter the opposite problem -- there are so many log messages, that it's hard to find a specific problem among them.

vog 10y ago
> there are so many log messages, that it's hard to find a specific problem among them. This is exactly my experience, too. Some programs get this even worse: They spam you with lots of useless information, yet when something goes wrong, you don't get the information you need. Instead, you have to rerun it to increase the verbosity even more. So ... if I have to rerun and having a hard time trying to reproduce the issue anyway, why did it spam me in the first place?

throw2016 10y ago

I think using the word 'philosophy' is like antimarketing. People have a kneejerk reaction to the word as something unchanging and stuck in the past and it lends itself easily to negative connotations. Take an example. Build small components that can be reused. Its like SOA way before SOA came into use and makes perfect sense. Now criticizing that is much more difficult and will require technical depth than just dimissive comments about 'unix philosophy'. In this case this is the first I've heard of a 'philosophy' of silence and it is often not golden. From a technical perspective its important for users to get feedback and not generic unhelpful error messages or commands disappearing. Fortunately on Linux logging is usually quite good and most experienced users can pinpoint errors quite quickly but options like -v, --v, -vv, -vvv far from helping often increase technical load.

dangravell 10y ago

The Unix philosophy of small, modular processes feels right to me, as a user and a coder. However the business and product developer in me wonders how I apply this to building more complex systems. Normally this involves building multiple functionalities. Does the philosophy say I shouldn't build "systems" that are complex and do multiple things? Or does it talk about how these should be implemented, as co-operating processes?

edblarney 10y ago
The 'do one small thing and do it well' philosophy is at least contentious in the general sense. Reality: no unit exists outside the context of it's ecosystem. Ergo, the API to that unit, and the degree to which it integrates with the other pieces is paramount. The 'do one thing and do it well' ideal implies almost a kind of 'unit sovereignty' that in many cases does not exist. In large, complex systems, 'units' can only view as parts of a greater whole. 'What they do' is almost less important than 'how well they fit'.

mojuba 10y ago

I always liked how MacOS loads silently without annoying the user even when it does some "hard" stuff like fsck. Generally I think engineers need to fight the temptation to show off the importance and complexity of their software by spitting out all the unnecessary details and logs.

michrassena 10y ago
I generally like how Windows and OSX both load silently when things go right too. Text on a black screen, to your standard computer user, looks like an error at worst and just a bunch of junk at best. Most Linux systems I've used, and I know when talking about Linux distributions someone can always find an exception, print a bunch of stuff when they start up.
kosma 10y ago
One way to completely break a Mac user out of their comfort zone is to switch the machine into verbose boot mode (sudo nvram boot-args=-v). Makes it look like old Slackware.
flukus 10y ago
Don't all of the "user firendly" linux distros do this too?

pdkl95 10y ago

> There is no single, standardized statement of the Unix philosophy They could at least link to tAoUP[1]. [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html

augustk 10y ago

One consequence of "the rule of silence" is that sometimes it is not obvious if a command is processing data or waiting for input, there is no visual difference.

pwdisswordfish 10y ago
You can often just check by hitting ^D, but yes, this is a workaround, not a fix.
ddalex 10y ago
This is why well-behaved programs prompt for input. Like bash, e.g.
- bluetomcat 10y ago
  With cat being the notable exception :-)
  - marcosdumay 10y ago
    And grep. Programs that use the input and output to carry data around can not show prompts to the user.
    - athenot 10y ago
      A workaround is to prompt on STDERR. Data input will enter the same place, and output will be distinguished from the text for prompts.
laumars 10y ago
That's more an occasional annoyance than a real problem though. The only commands that don't prompt when waiting for input are commands that are written specifically for stream processing from stdin. In which case the user should already be aware of it's behaviour because they're either already familiar with the command or have have consulted it's man page (or similar reference) before executing it. So the unprompted waiting for using input is a bug in a shell script / command line pipe and thus usually pretty quick to debug. Going back to the man page point: I will granted you that not everyone does check what a program does before running it. Sadly in those instances there's little you can do to protect them from themselves. It's similar to how you cannot protect people from blindly copying and pasting code from the internet. If someone is willing to run a command "blind" then the usefulness of the output is the least of their worries.

mvindahl 10y ago

[ ... ]

kozak 10y ago

Simplicity is always a virtue.

borplk 10y ago

To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other exotic ways of dealing with the problem. Oh you don't like that output? Easy! pipe that crap into sed then awk then perl then cut then wc and you're golden! When you get tot that point you have to understand that you have chosen to ignore the fact that the data you are dealing with must be represented in something much closer to a relational database than lines of ASCII text. Logging is another area you see the consequences of this. A log is not a line of text. Repeat after me a log entry is not a damn line of text. "Oh but isn't it neat you can pipe it to grep?" NO! No it's not neat, maybe it was neat 20 years ago. Today I want that damn data in a structure. Then you can still print it out in one line and pipe it to grep all you want. Another area that you see the unfortunate side effects of this philosophy is with the mess of file-based software configuration. Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted. I want my software configuration stored in a database not in a bunch of fragile files with made up syntax that are always one typo or syntax error away from being potentially silently ignored. The fetish for easily-editable ASCII files and escaping from structure is holding us back. Structured data does not automatically imply hidden and inaccessible, that's a matter of developing appropriate tooling.

skrebbel 10y ago
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware of the downsides of this philosophy. If not, try configuring IIS.
- rtpg 10y ago
  Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many versions of " get file created timestamp from ls" do we need? Something Windows does get right is the clipboard. You place a thing on the clipboard, and when you paste, the receiving program can decide on the best representation. This is why copy-pasting images has worked so magically. I could see an alternative system where such a mechanism exists for shell programs.

teddyh 10y ago

See also the following relevant chapters of The Art of Unix Programming: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450 http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id... http://www.catb.org/~esr/writings/taoup/html/ch11s09.html http://www.catb.org/~esr/writings/taoup/html/ch11s09.html

pgt 10y ago

Spolsky addressed this cultural difference between the Windows and Unix world in 2003: https://www.joelonsoftware.com/2003/12/14/biculturalism/ https://www.joelonsoftware.com/2003/12/14/biculturalism/ At its core, it is about putting humans before computers. Engelbart coined HCI as Human Computer Interface, not CHI. This philosophy steered my product designs ever since I read that as a teenager.

digi_owl 10y ago

I love this rule, as it is the opposite of what modern computing does. When i plug something into a Windows PC i get a multitude of beeps and popups saying it did everything right. But if something goes wrong there is a eerie silence and i have to dig into the error hex dumps to hope i find anything useful at all (or just reboot and hope it works right on second try).

stratigos 10y ago

love this article. the past paragraph is great - i often claim that stores do their best to drive me away by playing horrible music and making sure i am as annoyed as possible with no hope of being able to focus on purchasing something.

kulu2002 10y ago

I think this article gives good perspective regarding User Exp of system. Windows is made for much wider audience whereas UNIX is used by skilled people. I think its inappropriate to compare both philosophies with regards to this article.

emodendroket 10y ago

I wish I could find that old thing about ordering a burger at the Unix restaurant, where the clerk keeps giving you cryptic responses when you order wrong and then, when you do successfully order, says nothing, leaving you wondering whether your order has been accepted or not.

enigmango 10y ago
Probably this: http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.html http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.h... I hadn't heard of it until now. Thanks for the good read!
- emodendroket 10y ago
  That's the one.

kkotak 10y ago

It is refreshing to see no author name attributed to the text.

Edward16 10y ago

You need a savvy hacker,one who specializes in Expunging Criminal Records and Change of University Grades. Contact edwardsnowcare@gmail.com One who would be able to carry out and successfully execute hacks on your behalf while keeping it all discrete and under the radar.