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

231–240 of 318 posts

Re: The Rule of Silence (2006)

#231

Post by Slackwise »

tim333 wrote: post #155
yason wrote: post #149

Earlier quoted context omitted.

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

YAML is a superset of JSON, but is much more human readable:

http://yaml.org

This means you can give it JSON when you have JSON, but otherwise use the nicer format when possible.

Re: The Rule of Silence (2006)

#232

Post by closeparen »

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…

A somewhat decent middle ground, which my employer uses a lot, is CLIs that output JSON. You pipe them to JQ to do "selects" on the data structures in a reasonably clear and compact way.

Re: The Rule of Silence (2006)

#233

Post by chei0iaV »

emodendroket wrote: post #173
chei0iaV wrote: post #121

Earlier quoted context omitted.

The problem is that now simply providing user-friendly output is not enough. For every program or script you throw together you need to provide the text output for the user, and then the type object stream for piping. And then, the user would need to read documentation to see how to access each piece of data, what data type it is, what data type the other command takes, and maybe consider how to convert one to the ot…

> The problem is that now simply providing user-friendly output is not enough. For every program or script you throw together you need to provide the text output for the user, and then the type object stream for piping. In PowerShell if the result of a command is just an object the object is pretty-printed to the console in practice ends up looking pretty much like what a Unix command would have given you.

With generic pretty-printing, your program output becomes generic.

Compare the output of "df -h" vs the PowerShell equivalent "gdr -psprovider filesystem", for example. One provides the data in dense (easy to follow) rows, while the other spaces it out across the whole screen, leaving large gaps of empty space around some columns while also cutting off data in others. The difference is especially noticeable of you have network shares with long paths.

PowerShell is probably nice for scripting, but I wouldn't want to have it as my shell.

Re: The Rule of Silence (2006)

#234

Post by jstanley »

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…

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

The systemd journal works how you describe, and it is very painful to interact with. I'll take plaintext logfiles any day of the week.

It's fine if you want to interact with the log in ways that have been designed into it. But:

- it's harder to work out what you can delete to free up space in an emergency

- it's harder to get logrotate to do what you want

- it's harder to use "tac" to search through the log from the bottom up

> I want my software configuration stored in a database

So now you can't put comments in your config, you can't (as easily) deploy config with puppet, or in RPMs. You can't easily diff separate configs.

Re: The Rule of Silence (2006)

#235

Post by DonaldFisk »

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…

https://web.archive.org/web/20110718135417/http://www.dina.d...

explains how to exit vi.

Re: The Rule of Silence (2006)

#236

Post by kosma »

mojuba wrote: post #62

I always liked how MacOS loads silently without annoying the user even when it does some "hard" stuff like fsck. Generally I think engineers need to fight the temptation to show off the importance and complexity of their software by spitting out all the unnecessary details and logs.

One way to completely break a Mac user out of their comfort zone is to switch the machine into verbose boot mode (sudo nvram boot-args=-v). Makes it look like old Slackware.

Re: The Rule of Silence (2006)

#237

Post by pwdisswordfish »

restalis wrote: post #179
pwdisswordfish wrote: post #77

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.

"GUIs can follow or violate the Rule of Silence just as well." It would have been nice if this was permitted to be violated only by GUIs. Ask about the first-time *nix experiences before the GUI-embracing era and one of the few things they were noticing was the continuous text-spitting. For instance, that was happening on boot and OS loading sequence (and still happens, now only being hidden by default with splash-sc…

Booting up is a bit of a special case that I'd actually be willing to carve out an exception for. When the boot-up goes wrong, it's often due to causes so deep that they leave you with very few means of diagnosing it or showing an error message. If the booting process hangs, having a rough idea at what stage it happened can be very helpful. Without these messages, discovering the cause of failure would be much harder.

The boot-up splash screen hardly even counts as "GUI" anyway.

Re: The Rule of Silence (2006)

#238

Post by emodendroket »

chei0iaV wrote: post #233
emodendroket wrote: post #173

Earlier quoted context omitted.

> The problem is that now simply providing user-friendly output is not enough. For every program or script you throw together you need to provide the text output for the user, and then the type object stream for piping. In PowerShell if the result of a command is just an object the object is pretty-printed to the console in practice ends up looking pretty much like what a Unix command would have given you.

With generic pretty-printing, your program output becomes generic. Compare the output of "df -h" vs the PowerShell equivalent "gdr -psprovider filesystem", for example. One provides the data in dense (easy to follow) rows, while the other spaces it out across the whole screen, leaving large gaps of empty space around some columns while also cutting off data in others. The difference is especially noticeable of you ha…

You can pretty easily pass it to select and get just the properties you care about, or you could output to a different format with the various out- commands. I find it pretty good as a shell.

Re: The Rule of Silence (2006)

#239

Post by StRoy »

pwdisswordfish wrote: post #77
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…

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.

Talking about the rule of silence in GUIs, I wish I could slap the eurocrats who decided to force websites to show the cookie warning on a first visit of all websites. Did they even understand the consequence and wasted time of what they were doing? Having to click all the time to get this dumb warning off?

Of course some websites had to do it in an even dumber way than the law asks for. Like slashdot: http://i.imgur.com/5Fp0nmo.png

This is what greets the French every time slashdot decides to forget you agreed to let them put cookies on your computer and you need to click continue before you can get to the actual website.

The law actually made it worse for the people it's supposed to protect (those who might refuse cookies for privacy?) because those warning then will stick around like glue if they can't give you a cookie to remember you accepted their existence.

Re: The Rule of Silence (2006)

#240

Post by JdeBP »

bandrami wrote: post #230
TeMPOraL wrote: post #221

Earlier quoted context omitted.

Config files are less of a problem. The issue is with programs, which you want to use with pipes. Each has its own undocumented, arbitrary pseudo-structure with often inconsistent semantics, optimized for viewing by user.

What programs are you thinking of? Maybe this is my sysadmin bias but about 90% of my UNIX tools usage is on config files...

Let me suggest an incendiary example: systemd

systemctl status wibble.service : Displays human-readable information, with colours, line drawings, and variable-length free-form text; that is exceedingly hard for a program to parse reliably.

Contrast with

systemctl show wibble.service : Outputs machine-readable information, in systemd's favourite form of a Windows INI file.

Post reply on HN