Live data from Hacker News

The Rule of Silence (2006)

linfo.org

71–80 of 318 posts

Re: The Rule of Silence (2006)

#71
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…

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.

Re: The Rule of Silence (2006)

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

Re: The Rule of Silence (2006)

#75
post #66

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.

This is why well-behaved programs prompt for input. Like bash, e.g.

Re: The Rule of Silence (2006)

#76
post #75
post #66

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.

This is why well-behaved programs prompt for input. Like bash, e.g.

With cat being the notable exception :-)

Re: The Rule of Silence (2006)

#77
post #74

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 ex…

The text-oriented nature of Unix may be a mistake, but the Rule of Silence is not concerned with it. It is about not overwhelming the user with information they are not interested in. GUIs can follow or violate the Rule of Silence just as well.

Re: The Rule of Silence (2006)

#78
post #74

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 ex…

I'm with you when it comes to structured data, but plz no more data bases. these config files do not need to be centralized. I am thinking more in the direction of a parser that could check the validity of a configuration...

Re: The Rule of Silence (2006)

#79
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…

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.

then it should be named `sendKill` imho...

Re: The Rule of Silence (2006)

#80
post #74

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 ex…

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.

Post reply on HN