371–380 of 616 posts
Earlier quoted context omitted.
I meant that more in terms of IPC (e.g. in pipes), but most of those use cases happen to be adequately handleable by YAML specifically, so yeah, why not?
Ideally a simplified subset of YAML; the full specification suffers from feature creep and has actual bugs.
Earlier quoted context omitted.
S-expressions are very nice, and have the unequalled property of being simple enough to serve as a syntax for an entire programming language, but as a data type it is at best on the level of JSON. If one were to design a new data format for pipes, I would hope one would aim a little higher than that. Going from plain text lines to JSON or sexps would simply not be worth the infrastructure retooling.
What lies above JSON or S-expressions, XML? Or some binary format? If I had to guess, I'd say the issue with JSON and the like is how to deduce types (and the limited types available) combined with the issue of special characters in names and strings. XML goes a long way towards fixing that, but at the cost of a lot of extra bloat. A binary format with a nicely defined header might work, but those formats tend to not…
Most of the author's criticisms around the Unix Philosophy™ (aside from perhaps the performance aspect) would be solvable in two steps: 1) Standardize on some structured text serialization format (I like YAML for this) 2) Write a new shell Both of these things are compatible with the Unix Philosophy™, and thus said Philosophy is nowhere near collapse. Rusty around the edges, sure, and maybe with some asbestos in the…
2) I'm writing a new shell! http://www.oilshell.org/blog/ 1) This is an appealing idea, but my claim is that there's no single serialization format that will work. (Or if there is one, it has yet to be invented.) More detail here: https://www.reddit.com/r/oilshell/comments/5x5rgg/pipes_in_p... There's nothing stopping anyone from using structured data over pipes, but I think it's a mistake to assume there will be or…
Then I'm not sure how the problem would be solved. The main reason why "everything should be plaintext" is problematic (aside from being inefficient storage-wise) is that there's no "standard" format. My interpretation of the article's criticisms is that overreliance on tools like awk is the problem, not the solution.
Hence, the recommendation to just standardize on YAML (or some stricter subset thereof). If unstructured data is really needed in the pipeline, then it can easily be encapsulated in an ordinary YAML document. This would unify the strengths of the Unix way (ease of human inspection) and the PowerShell way (ease of plugging arbitrary tools together without needing to stick a bunch of text filters all over the place).
That was a sad thing to read, the author is so clueless they don't even know when the reasons they imagine something might have been broken are wrong. Back when UNIX was born the character was a first class citizen in every computer on the planet, and many languages used it as part of their syntax. Static binaries were invented when Sun and Berkeley co-developed shared libraries and there needed to be binaries that y…
> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today . I feel a little bit gross every time I have to write a bash sh…
No, we can't do better today. We may start something better today and enjoy it in 40 years, but for the time being, these are the tallest giants' shoulders we have.
That was a sad thing to read, the author is so clueless they don't even know when the reasons they imagine something might have been broken are wrong. Back when UNIX was born the character was a first class citizen in every computer on the planet, and many languages used it as part of their syntax. Static binaries were invented when Sun and Berkeley co-developed shared libraries and there needed to be binaries that y…
But I'd submit that the central thesis-that it is somewhat ridiculous to adhere to many of these conventions simply because they are established-is a very good one.
We have learned so much about how to make computer systems better and almost none of it is applied to Linux. The Linux kernel in particular is the work of brilliant people using archaic methodologies and adopting conventions that have long since ceased to make sense.
Earlier quoted context omitted.
The famous "each tool does just one thing well" mantra is also a depressingly overblown myth. Among the current Unix tools, there is a ridiculous amount of overlap. That's why we have both "ls" and "find", even though they do the same thing conceptually. "ps" has column output, but the way it formats, sorts, selects etc. columns is reinvented and not transferable to other tools such as "lsof" and "netstat", not to me…
Powershell did one thing wrong, in that its tools emit objects , not data . In other words, they emit data with behavior (methods). This, in turn, imposes the CLR object and memory model on the whole thing, and makes the pipeline impossible to use between distinct processes. The right way to do this is to pick some reasonable text-based structured interchange format - s-exprs, JSON, whatever. Actually, it wouldn't be…
Earlier quoted context omitted.
> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today . I feel a little bit gross every time I have to write a bash sh…
> why be content with the existing design!? Because backwards compatibility is more important. We can't just throw everything away every couple of years. Besides, who is to tell that the newer design will be better? Judging by the history of our industry, I have some serious doubts.
As much as it's popular to think otherwise, this isn't true. Taken as a whole, newer things are more often than not better than older things.
For example, cryptography has been on a huge march upward since the days of Unix crypt().
"How can we recursively find all files with \ name in folder foo?" Whenever someone tries to critique UNIX they always make up these nonsensical problems. No UNIX user would intentionally name a file with a forward slash, a space, a semicolon, etc. But I will play along. To find these files, a number of ideas come to mind. Maybe the easiest would be to use mtree to make a file specification and then search the specif…
> How can we recursively find all the files with \ name in a folder foo? The correct answer is: find foo -name '\\\\'
No, the correct answer:
% find foo -name '\\'
foo/\
The single quotes prevent the shell from performing escaping. Find does need escaping, and that's the only layer that does, so the correct answer has two backslashes.