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

91–100 of 318 posts

Re: The Rule of Silence (2006)

#91

Post by fnj »

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

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.

Parsing columns of text with awk or any other text tools is vexingly problematic. How do you even define "column"? What if columns contain whitespace? How do you differentiate that from the whitespace between columns?

Re: The Rule of Silence (2006)

#92

Post by cyphar »

rtpg wrote: post #87
skrebbel wrote: post #80

Earlier quoted context omitted.

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…

Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many v…

> What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many versions of " get file created timestamp from ls" do we need?

Aside: that's what the stat command is for. My big concern with types is how would you make sure that the output of a command will always have the right types? Otherwise you'll have runtime type errors which would be just as bad as runtime parsing errors.

Re: The Rule of Silence (2006)

#93

Post by nailer »

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?

CSON or .desktop / .service or something similar is immediately understandable to most people and doesn't waste time with unnecessary tokens like XML does.

Re: The Rule of Silence (2006)

#94

Post by Chris2048 »

Ianvdl wrote: post #81
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…

> 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. The amount of tooling that surrounds text is vast and has evolved over decades. You cannot replace that with a single database and call it better. I can place the majority of my config files in git and version them. I can easily perform a full…

> The amount of tooling

Or the amount of cruft.

> git

Any structured data can still be serialized and diff'd, but it isn't always the clearest. Where is the contrast here?

> made up data structures?

so standardize the non-text format

> Databases do not make you immune from typos

Depends on the constraints. There are few on text files, possibly excluding sudoers.

If you aren't sticking to good practice you can just as easily rm a text file.

> has a bug or vulnerability?

What happens when the kernel has a bug or vulnerability? There are quite a few mature db systems. Plus, all text files depend on the file-system, which is why you store root on something stable like ext (still depends on hdd drivers though, unless you have some some ramfs on boot).

> years of experience and fine-tuning

Can you describe specifically what that experience is, and what the "fine-tuning" is?

Re: The Rule of Silence (2006)

#95

Post by kagamine »

martijn_himself wrote: post #33

I wish people would live by this rule more often.

User kagamine is reading your comment.

User kagamine has read you comment.

User kagamine has processed your comment.

User kamamine came up with a barely witty response.

User kagamine has included the barely witty response for your amusement and irritation.

User kagamine hopes to not be banned for this trivial response.

Follow me on TwitFace for more like this and pictures of food.

This is the world we live in, the Rule of Silence seems like a unique and valuable asset to Unix in this day and age.

Re: The Rule of Silence (2006)

#97

Post by Vogtinator »

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.

Re: The Rule of Silence (2006)

#98

Post by chrisweekly »

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…

Great points, esp about logfiles. So grateful to have discovered lnav --http://lnav.org -- an amazing little CLI tool with embedded sqlite engine and regex support. It solved all my logfile parsing / querying problems, and then some.

Re: The Rule of Silence (2006)

#99

Post by TeMPOraL »

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?

Like S-expressions don't exist. Or even goddamn JSON. Come on, we don't have to jump from one stupidity (unstructured text) to another (using XML as a data representation format).

Re: The Rule of Silence (2006)

#100

Post by karl42 »

verinus wrote: post #78
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…

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.
Post reply on HN