Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rule of Silence (2006)

linfo.org

Post reply on HN
Print view View original

41–50 of 318 posts

Re: The Rule of Silence (2006)

#41

Post by TickleSteve »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". 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…

you already have a tool to check whether processes exist... 'ps'.

This is the essence of 'small, single purpose programs that work well with each other' rule.

Re: The Rule of Silence (2006)

#42

Post by nabanics »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". 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…

kill sends a signal, that's all it does. It doesn't care about what the process did with it.

Re: The Rule of Silence (2006)

#43

Post by stevedonovan »

cyborgx7 wrote: post #8
zeveb wrote: post #6

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…

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.

To paraphrase Keynes, in the long run we are all fools. (Except for Alan Kay, apparently)

Re: The Rule of Silence (2006)

#45

Post by return0 »

vog wrote: post #26
xg15 wrote: post #5

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…

> 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 for information ~ ~ type :q to exit ~ type :help or for on-line…

to be fair thats not enough either. someone might accidentally have pressed 'a' , and now good luck understanding how to get out of it without having a crash course on vim

Re: The Rule of Silence (2006)

#47

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

Re: The Rule of Silence (2006)

#48

Post by grive »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". 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…

kill sends a signal. It has no bearing over what the signal does and whether the result is what was expected.

Re: The Rule of Silence (2006)

#49

Post by pwdisswordfish »

cyborgx7 wrote: post #3

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.

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.

Re: The Rule of Silence (2006)

#50

Post by grive »

renox wrote: post #28

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.

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.

Post reply on HN