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.

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.

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.

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.

Spolsky addressed this cultural difference between the Windows and Unix world in 2003: 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.

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.

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.

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

> 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

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

I wish people would live by this rule more often.

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.

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/ch11s09.html

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?

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.

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.

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

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.

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.

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.

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

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.

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.

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

Simplicity is always a virtue.

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

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

[ ... ]

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

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

This page looks very nice