The Rule of Silence (2006)
linfo.org
The Rule of Silence (2006)
1–10 of 318 posts
Re: The Rule of Silence (2006)
#2I 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.
Re: The Rule of Silence (2006)
#3This 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.
Re: The Rule of Silence (2006)
#4"Rule of Silence" sounds so dark. Nope, I'll stick with "no news is good news".
Re: The Rule of Silence (2006)
#5Note 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.
Re: The Rule of Silence (2006)
#6Honestly, 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.
Re: The Rule of Silence (2006)
#7This 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.
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.
Re: The Rule of Silence (2006)
#8Honestly, 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.
Re: The Rule of Silence (2006)
#9Can help falling in love with the irony that most smartphones have an underlying unix version with mostly an oposite philosophy
Re: The Rule of Silence (2006)
#10This page looks very nice