Live data from Hacker News

The Rule of Silence (2006)

linfo.org

151–160 of 318 posts

Re: The Rule of Silence (2006)

#151

Earlier quoted context omitted.

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…

Structured text is good. Very good, in fact. It might even be idea. structured binary data , less so, at least as a storage format. I want to be able to look at your file format using tools that haven't been specialized to the task. Is that so wrong?

A text editor is specialised to the task of viewing and modifying text in a certain format.

Re: The Rule of Silence (2006)

#152
post #57
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…

> It's often a stupid rule. By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.

But there is a limit to much respect you should pay to your elders. UNIX was invented over ten computer generations ago, and it's inventors couldn't possibly have imagined the world we live in today. And given that Windows is the dominant desktop OS, not Linux, the "decades of useful outcomes" favors my argument so I don't know who is the ignorant one.

Re: The Rule of Silence (2006)

#153
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 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.
Speaking as someone who's in the process of automating configuration management on Windows, I'll say that this is _much_ easier said than done. Imagine something like Active Directory Federation Services, which stores its configuration in a database (SQL Server) and offers a good API for altering configuration data (Microsoft.Adfs.PowerShell). Instead of using a generic configuration file template---something supported by just about every configuration management system, using a wide variety of templating mechanims---I must instead write a custom interface between the configuration management system and the AD FS configuration management API. Contrast that with Shibboleth, which stores its configuration in a small collection of XML files (i.e., still strongly typed configuration data). These I can manage relatively easily using my configuration management system's existing file templating mechanism---no special adapter required. I can easily keep a log of all changes by storing these XML files in Git. I can put human-readable comments into them using the XML comment syntax. The same goes for configuration files that use Java properties or JSON or YAML or even ini-style syntax, not to mention all the apps that have configuration files that amount to executable code loaded directly into the run-time environment (e.g., amavisd-new's config file is Perl code, SimpleSAMLphp's is PHP, portmaster's is Bourne shell, portupgrade's is Ruby, and so forth).

In short, your configuration database scheme is like an executable, whereas text config files are like source code (literally, in some cases). I'd much rather work with source code, as it remains human readable while at the same time amenable to a variety of text manipulation tools. Databases and APIs are more difficult to worth with, especially from the perspective of enterprise configuration management.

Edit: See also http://catb.org/jargon/html/S/SMOP.html.

Re: The Rule of Silence (2006)

#154
post #15

Earlier quoted context omitted.

> 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

See also http://bropages.org

User-submitted and voted-upon examples for commands.

(hadn't seen tldr, looks great, I'll check it out)

Re: The Rule of Silence (2006)

#155
post #149
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…

> If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. What kind of tooling might work with ad-hoc structured data and still getting all the tools to talk with each other like in Unix? How would it work without having to write input parsing rules, data processing rules, and output formatting/filtering/composing rules for each tool? I suspect that t…

>it's not very popular to pass around structured data

There's an awful lot of JSON that gets passed around. That seems a reasonable compromise between readable text and some sort of structure.

Re: The Rule of Silence (2006)

#156
post #34
post #26

Earlier quoted context omitted.

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

Someone unfamiliar might just be dumped into vi because some other program thought it'd be great to open a text editor, e.g. for a commit message. You're unlikely to run vi intentionally unless you also know you want to run vi and how to exit, I guess.

I do think distros should change their default $EDITOR to nano.

Re: The Rule of Silence (2006)

#157
post #75

Earlier quoted context omitted.

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

With cat being the notable exception :-)

And grep.

Programs that use the input and output to carry data around can not show prompts to the user.

Re: The Rule of Silence (2006)

#158

Earlier quoted context omitted.

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.

Your comment was saved. Click OK to continue.

Precisely!

Re: The Rule of Silence (2006)

#159
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 o…

What you get from text + availability of source code = a set of practical documentation that shipped right where you needed it.

Microsoft forgot (and still forget) the documentation for Windows - if you want a nice A-Z reference for the bootloader, or kernel, or shell or IIS's configuration file or half the command-line tools, you're usually out of luck. The official place is often an inaccessible, badly-written knowledgebase article written from a task-based, usually GUI-based perspective.

It never mattered that they'd implemented a more coherent system full of better ideas, because the only way they'd tell you about it is through the GUI.

The MSDN CDs from 20 years ago were really good for a complete programmer's reference, but 1) I'm not sure how well they kept that up and 2) I could never find anything as comprehensive for sysadmins.

Re: The Rule of Silence (2006)

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

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

Well, powershell did solve that problem...

Post reply on HN