Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

361–370 of 616 posts

Re: The Collapse of the Unix Philosophy

#361
"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 specification.

Something like

    mtree -cp /foo |exec mtree -C
Any forward slashes, spaces, or other nonsense in filenames would appear as octal values.

If there are so many files that these specifications become large enough to cause problems with UNIX utilities, I import them into a database like kdb.

Is there a way to hide files from mtree? Maybe.

But at least with the UNIX concept for a system, the user can look at the source and see how it works.

The truth is, UNIX is not so impressive.

It is only the fact that the alternative systems for doing the types of things one does with UNIX have always been inferior/rubbish in the opinion of a certain set of informed users.

It is this contrast that makes UNIX seem impressive.

As usual, the author makes no suggestion or detailed comparison of any other alternative that can be used for doing the tasks one does with UNIX.

Re: The Collapse of the Unix Philosophy

#362

Earlier quoted context omitted.

Occasionally when I run out of analogies for why convoluted systems are not 'flexible', I reach for a half-remembered homage, that I encountered as a teenager, about the Chevy Straight 6. This was not a fancy engine. It was not a particularly powerful engine. Not a single thing on it or about it was exceptional. Because it was easy to work on and with add-ons and modifications it could be coaxed into doing things it…

The single most disastrous failing of UNIX is the assumption that everyone wants to be a programmer - or if they don't want to be a programmer, they damn well should become a programmer anyway. It's nonsense. Programming as it's done today - which is strongly influenced by UNIX ideas - is the last thing most users want to do. They have absolutely no interest in the concepts, the ideas, the assumptions, the mindset, t…

But it has to be. Linux can be super powerful. You can get very close to the metal. While a lot of people want to use it as an appliance, it really isn't. Just like all the other trades there is history which begets convention which begets culture. And like any good power tool you've got to know what you're doing, or you could get yourself into trouble.

The problem, I think, is that we seem to have trouble conceptualizing the schism that exists between the computing-as-a-tool users (aka the elites, power users, and programmers) and computing-as-an-appliance users (aka the computing mainstream). Both camps have wildly different wants, needs, and expectations.

Why can't both continue to exist separately? The elites don't want their tools weakened, and the mainstream just wants stuff to work. Split computing down the middle at desktops+laptops vs tablets+mobile+consoles and keep the separation clean. Now that we have iPads and whatnot there's no reason to keep nontechnicals on a PC if they don't want to be there... so why not let PCs return to the nerds?

Re: The Collapse of the Unix Philosophy

#363

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 shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought to be a scandal. Even if the author didn't frame the issue in the most charitable way for the earlier trailblazing generations, he's calling attention to the right issues.

In other words, if you couldn't justify something being designed a certain way de novo, why be content with the existing design!?

Re: The Collapse of the Unix Philosophy

#364

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…

The problem here is that most unix tools (ls being the exception) do double duty, they both emit output for other programs and output for the user. Which one you get and how the user output is presented being controlled by flags.

If you want them to only emit data in a standardized format you are implicitly cutting out the user.

Since direct use by a human is arguably the main use case, output formatting needs to be reindtroduced somehow. You could make some adapter that you always pipe into that handles most formatting concerns but it's unlikely that it will be truly general.

The only general way to do that is for the tool to output, along with the data, also some code that can be used to properly format the data.

So there are only three ways to solve this:

* Unix solution, with tools doing double duty and each tool having its own incompatible set of flags

* Actual programming language solution, tools emit pure data. Great for programming, bad for interactive use.

* Powershell solution, programs emit data+code: you are locked into some VM.

Re: The Collapse of the Unix Philosophy

#365
post #14

This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it. I feel so privileged to read this random guy's blog, and it's terrific that he eschews inflating his ego so well.

What bugged me more was the snippets designed to show how hard it is to write shell scripts. It looked like the author just didn't know enough about their tools: >How to touch all files in foo (and its subfolders)? find foo -print0 | xargs -0 touch find foo -exec touch {} \; I agree with the other commenters who think it's fine to write whatever you like on your own blog, I just feel that it went from interesting his…

If we take UNIX to mean the POSIX standard, it doesn't work because -print0 is not in POSIX, and neither is -0 for xargs.

Re: The Collapse of the Unix Philosophy

#366
post #352

Earlier quoted context omitted.

Of course there is a runtime, even C has a runtime. All programming languages, other than Assembly have runtimes. From the point of view of compiler design a runtime is everything required to support a programming language execution. On C's case, calling main (), floating point emulation, initializing globals, parallel code execution, thread locals.

Did you read the very next sentence?

Android uses AOT compilation to native code since ART replaced Dalvik, no different than iOS APPs.

https://source.android.com/devices/tech/dalvik/#AOT_compilat...

Even with Android N, they are interpreted, JIT compiled with PGO, and eventually AOT compiled to native code when the device in not being used.

Also iOS supports LLVM bitcode with AOT compilation at iTune infrastructure since iOS 9.

Language runtimes have APIs, that is how they interact with compiler generated code.

Using pure C on iOS means calling the API entry points of the Objective-C runtime

https://developer.apple.com/reference/objectivec/objective_c...

Re: The Collapse of the Unix Philosophy

#367

Earlier quoted context omitted.

One format for all use cases? Databases (passwd,group...), single-word files, key-value(-list?) files, rc files for a thousand programs? Great idea! We should use XML for that...

XML, YAML, JSON and s-expressions are all just flavours of representing trees . So yeah, any of that would be a much better idea than unstructured text, and yes, you can serialize all those use cases into trees. I'd steer away from XML for sake of efficiency and human-readability though.

Not everything is a tree, and neither XML nor JSON nor sexp are particularly efficient or "beautiful". And there is no canonic representation. You could strip all whitespace or indent all childs, but... And YAML for example has no nice way to put lists of single words on one line.

Re: The Collapse of the Unix Philosophy

#368

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…

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

Re: The Collapse of the Unix Philosophy

#369
post #157

Everyone should, at some point, read The Unix-Haters Handbook. A great deal of it is outdated or simply wrong, but it does have a running theme of a prediction that has largely been borne out: people assuming that all Unix's flaws are actually virtues and that if you don't think so, then you Just Don't Get It. It's not hard to see how this happened: since pretty much all computers that people normally interact with a…

> since pretty much all computers that people normally interact with are either running Windows or a Unix-like system, it has set up a dichotomy in people's minds I really wish undergraduate Software Engineering programs included a course that was a survey of operating systems, where you'd write the same program (that did a lot of IPC) on, say, base WinNT (kernel objects with ACLs!); base Darwin (Mach ports!); a unik…

My CS degree did something like that, both for programming languages and OSes.

I eventually got very surprised that not all universities do that.

Re: The Collapse of the Unix Philosophy

#370

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…

"if you couldn't justify something being designed a certain way de novo, why be content with the existing design!?"

Please, no. Don't convert system programming/engineering to the mess that is web development today.

Post reply on HN