The Rule of Silence (2006) • Hacker News Board

Re: The Rule of Silence (2006)

#251

Post by JdeBP » Tue, Dec 13, 2016, 4:42 PM UTC

palunon wrote: post #185

013 wrote: post #68

Earlier quoted context omitted.

Programs that put you into Vi, /should/ be calling $EDITOR, if $EDITOR is to to Vi(m), you should know how to use it. Also, if you ^C in Vi, you get the message: Type :quit to exit Vim

And what if $EDITOR is not set ? Vi is the standard POSIX editor, calling it makes sense.

Actually, defaulting from $VISUAL to vi and from $EDITOR to ex (or ed) is what -- strictly speaking -- makes sense.

Remember what the difference between $VISUAL and $EDITOR was intended to be. There's a whole range of places in Unix where there was, and even still is, a distinction between a line editor and a full screen editor. Consider, for just one example, the ~v and ~e commands in BSD Mail.

Now enjoy the discussion at https://news.ycombinator.com/item?id=13113556 .

Re: The Rule of Silence (2006)

#252

Post by borplk » Tue, Dec 13, 2016, 4:45 PM UTC

module0000 wrote: post #246

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

> How so?

As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group.

We end up with something that is hostile to both the humans and the computers, just in different ways.

In fact the argument of people like you for ASCII config files exactly demonstrates my point. You are fighting for your human-convenience against the machines.

> Holding us back from what?

By embracing and acknowledging that the humans and computers are not meant to share a language we free ourselves from this push-pull tension between human vs machine convenience.

We can develop formats and tooling that respects its human audience, that doesn't punish the human for making small superficial syntax or typo errors and so on.

And we can finally step the hell out of the way of computers and let them use what is suitable for them.

And at that point you could still have your SSH session and Vim/Emacs and blah blah blah and you could still view and interact with stuff as plaintext if you wanted to.

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

It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention.

For example you can silently break your cron jobs by leaving windows-newlines in them.

Perfect example of humans and computers sharing a language that is hostile to the human.

BAD BAD human! You stupid human why do you use bad Windows invisible characters? Use good linux invisible characters instead that are more tasty for your almighty lord Linux.

Re: The Rule of Silence (2006)

#253

Post by JdeBP » Tue, Dec 13, 2016, 4:52 PM UTC

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…

> Famous example: trying to exit vi

The interesting thing here is that in order to make this argument people forget that at least some new users know the "Press F1 for help" dictum, because that particular part of Common User Access was drummed into them from the start of their encounter with computers. The new users press F1 in vim (not vi) and how to exit is the second and third items on the screen.

(Press F1 in actual vi, and, in some terminals at least, it very informatively inserts the letter "P" into the document. (-:)

Re: The Rule of Silence (2006)

#254

Post by Chris2048 » Tue, Dec 13, 2016, 4:53 PM UTC

laumars wrote: post #128

Chris2048 wrote: post #94

Earlier quoted context omitted.

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

You can rm a database as well. In multiple different ways in fact. You can also put constraints on text files by forcing editing via a helper program (much like visudo and crontab do). In that regard the text format isn't much different from a database format aside the encoding of the data (it's probably also worth mentioning that you can - and some people do - store a database as flat text files if you wanted. They…

I'm not sure using a helper program has as many assurances around it, and manipulating data in a db often won't involve any 'rm' command, though copy/replacing a text file might.

> What do kernel bugs have to do with text vs binary formats?

you said "what if the db has a bug or vulnerability", my point is you have to rely on something, even the kernel. The difference is how stable these things are, and databases can be very stable.

> if your text files are compromised from a kernel vulnerability

not all kernel vulnerabilities will put the db at risk, it depends on the exposure to parts of the kernel. You can restrict the type and "fanciness" of the file-system a database will use if you know you don't need those additions, in the same way you use a stable fs for system files. You need a basic set of binaries one way or the other to access this data.

Re: The Rule of Silence (2006)

#255

Post by module0000 » Tue, Dec 13, 2016, 4:58 PM UTC

borplk wrote: post #252

module0000 wrote: post #246

Earlier quoted context omitted.

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

> How so? As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group. We end up with something that is hostile to both the humans and the computers, just in different ways. In fact the argument of people like you for ASCII config files exactly demonstrates…

> It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention.

I agree with you here, it's easy to write perfectly valid configurations that don't do what you intended. But throwing it all out seems like the baby going out with the bathwater to me.

In all seriousness, what if it was XML all around? I hate writing XML by hand, but that's part of the problem you are describing(ie human editing of raw config). XML parses very nicely, so difficulty of coding tools to speak XML is almost non-existent.

All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :)

Re: The Rule of Silence (2006)

#256

Post by chungy » Tue, Dec 13, 2016, 5:07 PM UTC

emodendroket wrote: post #180

zajd wrote: post #164

Earlier quoted context omitted.

> It's not meant to be user-editable I think that's kind of a stretch since regedit has been a part of windows as long as I can remember.

I'd say regedit is not really the preferred method for anyone to interact with the registry though.

I'd say that regedit is integral to day-to-day use of Windows.

Re: The Rule of Silence (2006)

#257

Post by eeZah7Ux » Tue, Dec 13, 2016, 5:11 PM UTC

michrassena wrote: post #229

pif wrote: post #57

Earlier quoted context omitted.

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

I think it's great that someone is questioning the way things have always been done, even it's just by calling it stupid. The hard part is coming up with something better. Unix at its core is still a product of the computing environment of the early 1970s. Not only that, it was a reaction to the complexity of Multics. What gave Unix an advantage at the time was how relatively easy it was to port to other architecture…

Verbosity is wasteful and time-consuming in today's environment as well.

Most people on HN are developers and not as fluent as system engineers in shells and UNIX tools. The need for minimalist, "silent" UIs comes with fluency. This is also true for network engineers and database administrators.

Re: The Rule of Silence (2006)

#258

Post by aloisdg » Tue, Dec 13, 2016, 5:13 PM UTC

Slackwise wrote: post #231

tim333 wrote: post #155

Earlier quoted context omitted.

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

TOML is far better

https://github.com/toml-lang/toml

Re: The Rule of Silence (2006)

#259

Post by eeZah7Ux » Tue, Dec 13, 2016, 5:14 PM UTC

pif wrote: post #162

bjourne wrote: post #152

Earlier quoted context omitted.

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.

> Windows is the dominant desktop OS So what? Is desktop computing all that matters? Networking, scientific computing, mobile telephone, don't they matter? Unix was never meant for looking magic to clueless users; it was meant for programmers, i.e. for people who use the computer and not just some programs written by other people. And, in its realm, it has been brilliant! Not perfect, but very good! By the way, here'…

On top of that, UNIX shell tools knowledge is not more required for casual desktop users (see Ubuntu) than batch files under windows.

Re: The Rule of Silence (2006)

#260

Post by borplk » Tue, Dec 13, 2016, 5:15 PM UTC

module0000 wrote: post #255

borplk wrote: post #252

Earlier quoted context omitted.

> How so? As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group. We end up with something that is hostile to both the humans and the computers, just in different ways. In fact the argument of people like you for ASCII config files exactly demonstrates…

> It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention. I agree with you here, it's easy to write perfectly valid configurations that don't do what you intended. But throwing it all out seems like the baby going out with the bathwater to me. In all seri…

> All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :)

Well that's exactly my point. I don't propose that we deploy it tomorrow but I want to see people do it and think about it and talk about it so our grand children can have better computing. Instead of sticking to the way of our fathers for all eternity.

XML as you identified has the same problem.

You need a human-dedicated interface that captures the intent of the human and you then convert that to something that the computer likes and tell them here ... this is what the human has ordered.

When we share the same raw input file with the computers that's when we set ourselves up for trouble.

Do I have the ultimate solution? No. Can I still complain about it being a problem? Yes.

One "solution" is a graphical rich interface with things like auto completion and validation and all that so it's much more capable of capturing the true intent of the humans. Basically the same way we interact with other web sites.

Imagine your bank told you to append a new text line to the end of "transactions.txt" file if you wanted to transfer money.

Now I put solutions in quotation marks because I know a GUI has other practical limitations and problems but you get the idea.

My point is as humans eventually we have to learn to graduate from sharing a rudimentary text language with the computer for the sake of short-term convenience.