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

21–30 of 318 posts

Re: The Rule of Silence (2006)

#21

Post by junke »

zeveb wrote: post #13
bluetomcat wrote: post #11

Earlier quoted context omitted.

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

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

Beyond text, structured data can give you actual functions or object instances. You can inspect a path object without dealing with escaped slashes, etc. For example, that's how I understand the "capabilities" security model: once you authenticate, you get an object which allows you to perform some tasks (https://en.wikipedia.org/wiki/Capability-based_security).

Re: The Rule of Silence (2006)

#22

Post by setrofim_ »

dom0 wrote: post #15
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…

> 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) $ man foo *scroll to the end with the EXAMPLES section* There should be an option for that. man --take-me-to-the-examples foo

You might find this intersting:

https://github.com/tldr-pages/tldr

Re: The Rule of Silence (2006)

#23

Post by bluetomcat »

zeveb wrote: post #13
bluetomcat wrote: post #11

Earlier quoted context omitted.

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

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

But column-oriented output is still structured and tools like AWK are meant to be a "programmable filter" on it. Reading or outputting deeply nested structures like JSON or S-exps would make it less practical to pipe programs together and instead have big "monolithic filters" with lots of options.

Re: The Rule of Silence (2006)

#24

Post by bjourne »

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

Re: The Rule of Silence (2006)

#25

Post by alkonaut »

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…

There are tons of good things to be said about "the unix philosophy". The Philisophy itself is good (do one thing, play nice together) but the implementation is crap to be honest.

The worse thing about the unix philisophy implemented as a unix shell environment is that programs (often) have only one interface, and that's used both for interactive use and as a programming API. This means, for example, that when we realize git version N has terrible default behavior given some arugments, we can't fix the behavior of those arguments t in git version N+1 because we would break it's API.

And yes of course - structured in/out, sane encoding handling etc. is just missing.

Re: The Rule of Silence (2006)

#26

Post by vog »

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 help        
  ~       type  :help version7   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.

Re: The Rule of Silence (2006)

#27

Post by anoother »

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…

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.

Re: The Rule of Silence (2006)

#28

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

Re: The Rule of Silence (2006)

#29

Post by [deleted] »

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…

[deleted]

Re: The Rule of Silence (2006)

#30

Post by junke »

setrofim_ wrote: post #18
zeveb wrote: post #13

Earlier quoted context omitted.

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

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

The example is not really interesting, because as you said there is already a simple structure. But programming with text becomes really tiresome after a while. For example:

    git blame -L ${LINE},+1 --porcelain ${FILE} | sed -n '/^author / {s/^author //; p}'
I would rather:

    (name (author (first (git blame file :line line))))
... where git blame returns a sequence of "blame" data for which I can retrieve the author easily (if you prefer pipes over function composition syntax, use threading macros). Then I don't have to worry about strange characters crashing my scripts randomly. Suppose I forgot to add the "^" symbol in my regexp (I can assume this, since you assume people forget parentheses), there could be situations where I would match too many lines.
Post reply on HN