
The Rule of Silence (2006) - riansanderson
http://www.linfo.org/rule_of_silence.html
======
borplk
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
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
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.

~~~
romaniv
_> What is the argument for shell scripts not working on typed objects?_

Typed objects can make it harder to pipe commands together. How do you grep a
tree when tree is an actual data structure and grep expects a list of items as
input? You would need to have converters. Either specific converter between
tree and list, or a generic one: tree->text->list.

 _> Something Windows does get right is the clipboard._

It useful, but the actual implementation is pretty bad. Opaque, prone to
security issues, holds only single item, cannot be automated.

~~~
JadeNB
> Typed objects can make it harder to pipe commands together. How do you grep
> a tree when tree is an actual data structure and grep expects a list of
> items as input? You would need to have converters. Either specific converter
> between tree and list, or a generic one: tree->text->list.

To be fair, untyped objects also require converters, but at _every_ boundary.
That is, instead of having some pipes of the form `program -> mutually
agreeable data structure -> program` and some pipes of the form `program ->
unacceptable data structure -> parser -> program` (as happens with a typed
language), you are guaranteed by a text-based interface _always_ to have pipes
of the form `program -> deparser -> text -> parser -> program`.

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

~~~
vog
_> Famous example: trying to exit vi_

To be fair, this has been fixed a long time ago. At least Vim (which is the Vi
installed on most systems) shows the following message on startup:

    
    
      ~                     VIM - Vi IMproved                       
      ~                                                             
      ~                      version 7.4.1829                       
      ~                  by Bram Moolenaar et al.                   
      ~                          [...]
      ~        Vim is open source and freely distributable          
      ~                                                             
      ~               Help poor children in Uganda!                 
      ~       type  :help iccf<Enter>       for information         
      ~                                                             
      ~       type  :q<Enter>               to exit                 
      ~       type  :help<Enter>  or  <F1>  for on-line help        
      ~       type  :help version7<Enter>   for version info
    

On the other hand, it doesn't show this message when you call "vi" with a
filename. But at least a beginner running "vi" for the first time should be
taken care by this.

~~~
ygra
Someone unfamiliar might just be dumped into vi because some other program
thought it'd be great to open a text editor, e.g. for a commit message. You're
unlikely to run vi intentionally unless you also know you want to run vi and
how to exit, I guess.

~~~
013
Programs that put you into Vi, /should/ be calling $EDITOR, if $EDITOR is to
to Vi(m), you should know how to use it.

Also, if you ^C in Vi, you get the message:

    
    
      Type  :quit<Enter>  to exit Vim

~~~
palunon
And what if $EDITOR is not set ? Vi is the standard POSIX editor, calling it
makes sense.

~~~
JdeBP
Actually, defaulting from $VISUAL to vi and from $EDITOR to ex (or ed) is what
-- strictly speaking -- makes sense.

Remember what the difference between $VISUAL and $EDITOR was intended to be.
There's a whole range of places in Unix where there was, and even still is, a
distinction between a _line editor_ and a _full screen editor_. Consider, for
just one example, the ~v and ~e commands in BSD Mail.

Now enjoy the discussion at
[https://news.ycombinator.com/item?id=13113556](https://news.ycombinator.com/item?id=13113556)
.

------
kbart
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
_> 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?

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

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

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

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

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

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

~~~
setrofim_
What would your example achieve? You're making the format more verbose and
error-prone (someone might easily forget to match a paren), without imposting
any additional structure over what is already implied by line breaks.

Though I do agree with your overarching point that some of the formats/outputs
could do with a more consistent structure. Perhaps something like YAML would
strike a good balance between structure and conciseness/readability...

~~~
pherq
> What would your example achieve? You're making the format more verbose and
> error-prone (someone might easily forget to match a paren), without
> imposting any additional structure over what is already implied by line
> breaks.

That particular example is fairly straightforward (at a simple level, passwd
files aren't complex), but being able to express arbitrary nested structure
would make various things a lot more straightforward. Line breaks and some
sort of tab/colon/what have you work fine if everything has at most two levels
of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the
random formats for files are fairly strict about what they parse, and the ones
that matter (e.g. passwd, sudoers, crontab) are conventionally edited through
tools that check the syntax before committing.

~~~
dagenleg
Maybe you shouldn't use arbitrary nested structures where you can go without?

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

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

~~~
augustk
I was more thinking of a situation where you have misunderstood the syntax of
a command or forgot to type an argument.

~~~
laumars
I did cover that point. :)

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

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

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

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

------
martijn_himself
I wish _people_ would live by this rule more often.

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

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

------
teddyh
See also the following relevant chapters of _The Art of Unix Programming_ :

[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id...](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450)

[http://www.catb.org/~esr/writings/taoup/html/ch11s09.html](http://www.catb.org/~esr/writings/taoup/html/ch11s09.html)

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

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

------
emodendroket
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
Probably this:

[http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.h...](http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.html)

I hadn't heard of it until now. Thanks for the good read!

~~~
emodendroket
That's the one.

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

~~~
withholding
No irony there.

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

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

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

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

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

~~~
pif
> It's often a stupid rule.

By the way, I haven't down-voted you, but I think I understand why others did.
Before calling stupid a pillar of a (programming) philosophy with decades of
useful outcomes, you should stop and ask yourself whether it's just a matter
of taste on your side or, even more likely, of ignorance.

~~~
michrassena
I think it's great that someone is questioning the way things have always been
done, even it's just by calling it stupid. The hard part is coming up with
something better. Unix at its core is still a product of the computing
environment of the early 1970s. Not only that, it was a reaction to the
complexity of Multics. What gave Unix an advantage at the time was how
relatively easy it was to port to other architectures and how few resources it
required. Universities and businesses could run it on cheap $50,000
minicomputers. It eventually outgrew a lot of its origins, but still. The rule
of silence makes the most sense on a slow terminal or a teletype. Verbosity is
wasteful and time-consuming in that environment.

~~~
eeZah7Ux
Verbosity is wasteful and time-consuming in today's environment as well.

Most people on HN are developers and not as fluent as system engineers in
shells and UNIX tools. The need for minimalist, "silent" UIs comes with
fluency. This is also true for network engineers and database administrators.

~~~
pif
> The need for minimalist, "silent" UIs comes with fluency.

No, it comes from wanting to reuse the tool!

Would you like your browser to open plenty of pop-ups with messages like _"
Congratulations! The font XYZ was successfully loaded from C:\foo\bar"_ or _"
That's incredible! I looked for a JPEG on server www.qqq.com ... and it was
there!"_? No, you wouldn't. And I wouldn't like "mv" to babble every time it
renames a file on the hard disk.

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

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

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

------
kozak
Simplicity is always a virtue.

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

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

------
mvindahl
[ ... ]

------
vacri
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_astonishmen...](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)

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

~~~
pif
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._

------
bendbro
This page looks very nice

