Live data from Hacker News

The Rule of Silence (2006)

linfo.org

291–300 of 318 posts

Re: The Rule of Silence (2006)

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

First, rule of silence has nothing to do with plain text. It applies to any human-machine interface including GUI and physical knobs.

Second, you are right about structured data and all. The only thing is that it's either impossible or extremely hard to achieve. Many have tried, all of them failed. Windows now has a mix of registry, file and database configs which is a nightmare and is much worse than any unix. AIX has smitty and other config management solutions which are a bitch to work with if you want something non-trivial. Solaris is heading this direction (actually it's heading to the grave but it's another story) and it's also not nice. There are a lot of other OSes and programs which tried to do it but failed.

This is much like with democracy: it's a terrible form of ruling, too bad we have nothing better. This is exactly what's up with unix configs and data formats. It is possible to make some fancy format and tools which will achieve it's goal for like 80% of the time. But it will cause huge amount of pain in the ass in the rest 20% and this is where it will be ignored and you'll end up with a mix of two words which is worse than one.

Re: The Rule of Silence (2006)

#292

Earlier quoted context omitted.

The Windows way of working is only "self-evidently" horrible if you're used to the Unix way of doing things. There are real defects that are legacy baggage (running as admin by default is not good, the registry probably shouldn't be a single database or at least should have better segregation between apps) but having a UI and having real objects in the shell isn't one of them. And I hardly think the registry and Powe…

> And I hardly think the registry and PowerShell, which came out nowhere near the same time, were conceived of at the same time. I believe that the registry, in a way, caused PowerShell. PowerShell works the way it does because Windows is structured data all the way down. A text-based shell a-la bash would not be very useful for Windows sysadmins. If you want to do Windows automation (e.g. on a cluster of windows ser…

Perhaps, but PowerShell wouldn't look the way it does without the CLR being ready to hook into either. And I could easily see just having applications that interact with the structured data but return text -- that's what all the old stuff did.

Re: The Rule of Silence (2006)

#293
post #87

Earlier quoted context omitted.

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…

Wow, the clipboard is really a thought-provoking comparison. I'm not sure if many people are quite aware of what you said, unless they've done desktop programming: when an application puts something on the clipboard, it can put multiple formats, so that when something else wants to retrieve it, it can use whichever format it prefers. This is how you get such good copy/paste interoperability between programs. What if…

Didn't the Amiga do something like this? (I'm not actually familiar with its OS, I've just seen allusions to how it handled file formats)

Re: The Rule of Silence (2006)

#294
post #276
post #245

Earlier quoted context omitted.

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.

What's in your $PSVersionTable? I'm doing this on windows 2008 server.

5.1 on Windows 10. Admittedly, I never really tried iwr on older versions. Heck, the last time I tried downloading something with PowerShell to a file I went the WebClient.DownloadFile route, so it's been a while.

You can probably install a more recent version of WinRM on that machine, though (or by now probably the open-source version of PowerShell).

Re: The Rule of Silence (2006)

#295

Earlier quoted context omitted.

ls, ps, du, df, ... pretty much all CLI tools. The kind you use in scripts.

All four of which users are enjoined, over and over again, not to try to parse the output of (particularly ls). That is, those are the tools specifically not meant to be connected by pipelines, but merely used for operator convenience.

...But how do you extract that data otherwise?

Re: The Rule of Silence (2006)

#296
post #87

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…

> How many versions of " get file created timestamp from ls" do we need?

none? 'ls' is for humans. 'stat' is for scripts.

Re: The Rule of Silence (2006)

#297
post #87

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…

How about protocol buffers and content negotiation? Your pipe figures out a proto that program a can emit and program b can consume.

ls -> repeated FileDescriptor files; | repeated string names;

Where FileDescriptor is whatever it needs to be, has all the info ls -l does. You have a heirarchy of outputs: if the next takes FileDescriptors, you give it FileDescriptors, if it doesn't you give it strings.

What would go to stdout goes through a toString filter.

Re: The Rule of Silence (2006)

#298
post #162

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

UNIX isn't dominant in the areas you mention now either (no, Android isn't UNIX). It has a niche among free software users and in networking devices but it is not common in other areas.

I.e. your "decades of useful outcomes" argument doesn't favor the point you are making because the opposite philosophy (a more verbose userland) has many times more "useful outcomes". Therefore, according to your own logic (which I don't subscribe to because I think popularity is a useless measure of sound design) you "should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance."

Re: The Rule of Silence (2006)

#299
post #282

Earlier quoted context omitted.

Options to select output? Sounds like advice from the Rule of Silence. But. - People above were just complaining about having to use sed to tweak output. I don't see why they would prefer a built-in filter to an external one. The external filter is far more flexible, and if that isn't enough, you can replace it. - I'm generally not a fan of applications that tailor their output to what they think the human wants. Unl…

Yeah, wow, all I have to do is write a bunch of regular expressions tailored to the unique output of this command instead of passing in a list of property names. It's so easy.

To add to that: a list of property names you don't even have to exactly know beforehand, since the shell can easily deliver you the exact data structure and metadata of any object (cmdlets, parameters, results,...) usable on the shell.

I find the idea baffling that basically having to have the whole syntax tree memorized instead of the shell providing it for me is somehow less of a "waste of cognitive energy".

Re: The Rule of Silence (2006)

#300
post #175
post #85

Earlier quoted context omitted.

I can see your argument for consistent structure--I definitely don't love vimscript or nginx's custom configuration language. But that doesn't require we jump out of text--JSON and XML are viable, provided they remain geared toward hand editing. It may be that given proper tooling for database-driven configuration it could be visible and accessible, but the fact is, I haven't seen timing that pulled that off.

JSON and XML are both horrible in their own ways, especially for use as configuration languages.

True, but my point is that the alternatives being proposed are vaporware. JSON works now. IMHO JSON is the least shitty of the shitty solutions that exist.
Post reply on HN