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

101–110 of 318 posts

Re: The Rule of Silence (2006)

#101

Post by TeMPOraL »

borplk wrote: 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…

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn, mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text.

I guess our industry is meant to run in circles, only changing the type of brackets on each loop (from parens to curly on this iteration).

Re: The Rule of Silence (2006)

#102

Post by ArkyBeagle »

borplk wrote: 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…

Structured data may or may not imply "hidden and inaccessible", but there's a lot of correlation between the two.

Re: The Rule of Silence (2006)

#103

Post by stevedonovan »

riskneural wrote: post #83
verinus wrote: post #78

Earlier quoted context omitted.

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

So, horribly unreadable xml config files?

Not necessarily. JSON is not bad, _if_ you allow comments. Even plain-jane key/value config files can be sanity-checked. I suspect part of the problem is that anything fancy like that is awkward to do in C, so people take the lazy way out.

Re: The Rule of Silence (2006)

#104

Post by ArkyBeagle »

TeMPOraL wrote: post #101
borplk wrote: 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…

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn , mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text. I guess our industry is meant to run in circles…

I can't disagree there. I've used SNMP in anger before. Underlying SNMP is the MIB.

People ran away screaming from it :)

Re: The Rule of Silence (2006)

#105

Post by TeMPOraL »

karl42 wrote: post #100
verinus wrote: post #78

Earlier quoted context omitted.

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

Maybe many tiny sqlite databases? Then you would not need to to centralize your data in a single database, but still do queries across different config files.

SQLite is a huge win. All the power of SQL, and you don't have to introduce system-wide and non-local dependencies.

Re: The Rule of Silence (2006)

#106

Post by teddyh »

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

If you want a fast way to read the EXAMPLES section only for a command, here is a shell function which creates an ‘eg’ command which only displays the “EXAMPLES” section of manual pages:

  eg(){
      MAN_KEEP_FORMATTING=1 man "$@" 2>/dev/null \
          | sed --quiet --expression='/^E\(\x08.\)X\(\x08.\)\?A\(\x08.\)\?M\(\x08.\)\?P\(\x08.\)\?L\(\x08.\)\?E/{:a;p;n;/^[^ ]/q;ba}' \
          | ${MANPAGER:-${PAGER:-pager -s}}
  }

 Usage:

  $ eg tar
  EXAMPLES
       Create archive.tar from files foo and bar.
             tar -cf archive.tar foo bar
       List all files in archive.tar verbosely.
             tar -tvf archive.tar
       Extract all files from archive.tar.
             tar -xf archive.tar
  $

Re: The Rule of Silence (2006)

#107

Post by TeMPOraL »

Vogtinator wrote: post #97
borplk wrote: 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…

You can just develop alternative tools and pipe JSON. Text and data in one. Pipes can transfer arbitrary data, so it's just the tools that you don't like, not the underlying mechanism.

Yeah, but that's the point. Pipes are fine. The tools suck, though. UNIX would be infinitely better if it defaulted to piping structured text instead of making each tool have to implement its own shotgun parser.

Re: The Rule of Silence (2006)

#108

Post by zodiac »

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…

> Also, the program is called KILL so one could be forgiven for assuming it's main purpose is to KILL things...

I think this is the source of the problem. kill really is just for sending signals.

In the "Unix philosophy" there's no standard way to end processes, normally you send it SIGTERM and hope that it catches that, cleans up and exits. If it doesn't it could be a bug in the program, or maybe the program uses SIGTERM with slightly different semantics (eg Celery will wait for its children's tasks to finish, and does the "normal thing" of exiting as fast as possible when it gets two SIGTERMS); in any case I think the idea is that it's a weird, non-standard situation and the user needs to explicitly send SIGKILL (kill -9), since doing so might be dangerous.

Re: The Rule of Silence (2006)

#109

Post by ArkyBeagle »

bluetomcat wrote: post #11
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…

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

Emphasis "are". Still.

Re: The Rule of Silence (2006)

#110

Post by stevedonovan »

Vogtinator wrote: post #97
borplk wrote: 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…

You can just develop alternative tools and pipe JSON. Text and data in one. Pipes can transfer arbitrary data, so it's just the tools that you don't like, not the underlying mechanism.

Modern tools should offer the option to write out JSON (with a proper spec, please). I can definitely see the value of a 'ls' variant that can do this, and I remember people discussing JSON-based shells. But not either/or! For example, the Rust compiler can now be persuaded to write out error messages in JSON.
Post reply on HN