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

241–250 of 318 posts

Re: The Rule of Silence (2006)

#241

Post by bandrami »

JdeBP wrote: post #240
bandrami wrote: post #230

Earlier quoted context omitted.

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.

Yikes. Makes me glad I run Slackware. Though I seem to recall from The Init Wars that it was precisely this quality of SystemD that made people lob the charge that it violated the "Unix philosophy"

Re: The Rule of Silence (2006)

#242

Post by JdeBP »

jslabovitz wrote: post #184
stevedonovan wrote: post #110

Earlier quoted context omitted.

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.

Modern tools are offering the option to write out JSON. Grepping /usr/share/man and /usr/local/share/man on my macOS system reveals a good dozen or so commands that take JSON as input or generate it as output. (Their man pages generally document the schema, too.) Most of the tools I've written myself also have JSON I/O.

* http://jdebp.eu./Softwares/nosh/guide/service-show.html

Jos Backus asked for the JSON option in 2013.

Re: The Rule of Silence (2006)

#243

Post by mr_overalls »

ygra wrote: post #133
Pxtl wrote: post #120

Earlier quoted context omitted.

The simple fact that the Registry doesn't have comments is ludicrous.

What database has? To clarify: The registry is a database for OS or application stuff (caches, settings, etc.). It's not meant to be user-editable and outside arcane trouble-shooting stuff you're unlikely to ever have to venture in there.

Oracle, for one, has had it for a long time.

"Use the COMMENT statement to add a comment about a table, view, materialized view, or column into the data dictionary."

https://docs.oracle.com/cd/B19306_01/server.102/b14200/state...

Re: The Rule of Silence (2006)

#244

Post by pwdisswordfish »

StRoy wrote: post #239
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.

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…

The 'best' part is that the only way to remember the fact that the warning was shown (and not display it any more) is to use a cookie or something functionally equivalent to one.[0] So instead of empowering people who wish to protect their privacy, these warnings push people even further to keep cookies enabled.

[0] Storing it server-side, per IP address, is obviously impractical.

Re: The Rule of Silence (2006)

#245

Post by ygra »

setq wrote: post #217
ygra wrote: post #142

Earlier quoted context omitted.

man iwr Oh, there's an OutFile parameter. Let's see what it does man iwr -param outfile How nice, it writes the response directly to a file instead of to the pipeline. The curl alias actually points to the very same cmdlet. Not to excuse bad examples on the internet (there are lots of people who fail to grasp PowerShell and still try to write articles and how-tos), but PowerShell having built-in documentation for com…

It doesn't work for large files. Try iwr with outfile on a 16Gb file on a 4/8Gb machine. Knowing all the edge cases, exceptions and places where reality breaks down is the problem. Where software should indeed work with the principle of least surprise, Microsoft have patented the principle of most inconvenient surprise. Also SO has one small comment about this which didn't exist when I discovered it. I had to use win…

Unless you also write things to the pipeline via -PassThru specifying -OutFile will read in 10K chunks and write them to the file. No memory apart from that buffer is used. Look at the source, it's public. My PowerShell instance uses 38 MiB of memory the whole time during the download, regardless of the file size.

Re: The Rule of Silence (2006)

#246

Post by module0000 »

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…

> Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted.

How so? I'm one of those people that like my SSH session, and in my case vim and "blah blah blah". I've contributed to countless open source software packages that you likely use with this method, and so have tons of other developers. Nothing is broken here, things are working great for everyone who reads the manual and follows it.

> I want my software configuration stored in a database not in a bunch of fragile files with made up syntax that are always one typo or syntax error away from being potentially silently ignored.

apache, postfix, haproxy, even vim are certainly not prone to silently ignore anything, just to name a few.

> The fetish for easily-editable ASCII files and escaping from structure is holding us back.

Holding us back from what?

I am both a developer and an administrator, and I've had all the fun with solaris/aix configurations that are often not stored in plain text that I care to have. If you also have this experience, and still feel the way you do, then I'd love to hear more. Otherwise, your rant comes off as "your way is hard, and I don't want to learn it!"

Look at all the available structures available for that plain text you speak of... XML, JSON, YAML, the list goes on. You are free to use one of those, then you have that structure you crave. There are plenty of areas that could use revolution, but UNIX-like configuration files are not one of them. There is no problem here. If you are making typos or mis-configuring your software, then you have a problem of your own creation.

Re: The Rule of Silence (2006)

#247

Post by jokoon »

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 split, because there was this article saying the opposite, that actually text is a pretty good format because it's simple, compact, and easily debug-able. On the other hand text is awful if you want to serialize data because parsing and searching text is one of the most CPU intensive thing.

Now, it's true that we should recognize where text is really inadequate, especially when indexing and searching is needed. Webpages, for example, should not be plain text.

I think the problem resides in programmers not being able to properly use and understand how a database works. Databases and their engines are black boxes, so it's normal if fewer developers want to to use DB like you say. Meanwhile dictionaries and B-tree are not very sophisticated algorithms, yet I see almost no programmers using them consciously. The less a programmer know about the tools he has in his hands, the less he will get benefits from it and thus he will start using easier things.

So really my thought is that the tools are not accessible enough. The concepts of file and database are so distant that it's completely impossible to work with both, but to me it should.

Re: The Rule of Silence (2006)

#248

Post by module0000 »

TeMPOraL wrote: post #223
mbrock wrote: post #171

Earlier quoted context omitted.

Heh heh, "someone in power." Who would that be? There's no authority to complain to about all this... Structured text formats come and go: S-expressions, SGML, XML, JSON, "modified JSON", etc etc etc... Fortunately the Unix tools work the same with any byte stream, pretty much, so they've survived gloriously since the 1970s. That's kind of the whole deal with "worse is better."

> There's no authority to complain to about all this... Whoever accepts patches to base UNIX system libraries would be a good start. > Fortunately the Unix tools work the same with any byte stream, pretty much, so they've survived gloriously since the 1970s. So would a structured text format, except you wouldn't be discarding and then recreating semantic information at every junction of a pipe.

> Whoever accepts patches to base UNIX system libraries would be a good start.

That can be you! Get to work, or pay someone else to get to work if the skills required aren't in your set.

Re: The Rule of Silence (2006)

#249

Post by romaniv »

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?

Typed objects can make it harder to pipe commands together. How do you grep a tree when tree is an actual data structure and grep expects a list of items as input? You would need to have converters. Either specific converter between tree and list, or a generic one: tree->text->list.

>Something Windows does get right is the clipboard.

It useful, but the actual implementation is pretty bad. Opaque, prone to security issues, holds only single item, cannot be automated.

Re: The Rule of Silence (2006)

#250

Post by michrassena »

bluetomcat wrote: post #227
michrassena wrote: post #199

Earlier quoted context omitted.

The thing about today's Unix Philosophy, epitomized by both the BSDs and Linux is that it's backward-looking. There's a Garden of Eden myth and everything. Look at the reaction to systemd. I remember getting fairly excited when Apple OSX first came out and quite a few of the configuration files were XML-based. Finally, a consistent format, but it wasn't pervasive enough. Even Apple couldn't see fit to break with the…

I would be so excited to see new operating systems which depart from POSIX completely and introduce new abstractions to replace the dated notions of hierarchical filesystems, terminals, shells, shared libraries, IPC, etc. The sad truth is that everyone targets POSIX because there is so much software that can be ported in order to make the system usable.

I agree. The "Unix compatibility layer" has killed so many interesting projects over the years. If systems research were still an academic pursuit, maybe there would be some interest in bringing a system like this to fruition. It would require a long-term investment in the design of the system foremost.
Post reply on HN