Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

Post reply on HN
Print view View original

191–200 of 616 posts

Re: The Collapse of the Unix Philosophy

#191

Post by trentnelson »

vram22 wrote: post #170
nickbauman wrote: post #91

Earlier quoted context omitted.

I love motorcycles too. I've owned many sophisticated bikes: Ducatis with their strange Desmodromic heads. With the ability to dial an exchange of torque to horsepower at the handlebars. Buells with their fuel-in-frame chassis. My current Suzuki even has 4 sensors in the airbox alone. One that measures the air input pressure. One that measures the oxygen level. One that measures the air temperature. Really amazing pe…

Interesting comment. Got to say I agree with the direction of it, to some extent - stable and powerful over newfangled and weak / unstable / buggy / done for glory rather than substance. Do you know about the Royal Enfield Bullet [1] from India? It is not at all as technologically sophisticated as the bikes you mention and others, but it is a fantastic bike to ride. They are selling it in the West, too, from some yea…

Hey, Royal Enfield! My uncle was behind the company that was the sole distributor of Royal Enfield for Australia/NZ for a good decade or so (sold the business a few years ago).

Re: The Collapse of the Unix Philosophy

#192

Post by nickpsecurity »

flukus wrote: post #122
Animats wrote: post #33

There are many early UNIX design decisions that have outlived their shelf life by decades. Probably the biggest one is that UNIX is, at bottom, a terminal-oriented multi-user time sharing system. This maps badly to desktop, mobile, and server systems. The protection model is a mismatch for all those purposes. (Programs have the authority of the user. Not so good today as in the 1970s.) The administration model also m…

> The protection model is a mismatch for all those purposes. (Programs have the authority of the user. Not so good today as in the 1970s.) I disagree, I think this is still the sweet spot between security and utility. Users have been trained to just click approve on any privilege escalation dialog.

The capability model is much more flexible. See Combex's desktop or "PowerBox's" for how simple it can be gor users to maintain POLA. Older system doing it was KeyKOS on IBM mainframes. KeyKOS + KeySAFE was strong architecture.

Re: The Collapse of the Unix Philosophy

#194

Post by TeMPOraL »

czep wrote: post #164

A lot of the author's criticisms are about UNIX utilities not gracefully handling filenames containing special characters. But seriously, who puts a newline in a filename? Instead of wasting time writing scripts that meticulously handle all possible edge cases, I'd much rather fix whatever broken process is putting control characters into file names.

"Doctor, it hurts when I do this."

"So don't do it."

The problem with filenames is just a symptom of the biggest problem of UNIX conventions - passing around unstructured text. Filenames should have one well-defined format (AFAIR kernel allows pretty much anything but the NULL character). That's it. For most applications, filenames should be opaque data blobs compared for binary equality. But because we're passing around unstructured text, each program has to parse, reparse, and concatenate strings via ad-hoc, half-assed shotgun parsers. Each program does it slightly differently, hence the mess.

Re: The Collapse of the Unix Philosophy

#195

Post by white-flame »

unethical_ban wrote: post #182
white-flame wrote: post #179

Some of my primary beefs with Unix, stated more concisely than the rambling article: 1) Text is for humans, and is generally incomprehensible to machines. Encodings, arbitrary config file formats, terminals, etc, are all piles of thoughtless one-off hacks. It's a horrible substrate for compositing software functionality, through either pipes or files. 2) Hierarchical directory structures quickly become insufficient.…

To 1: Computers are for humans. I like my configurations to be accessible to me, as well as my logs.

Who gets to decide what "accessible" means? Too many unix programs have their own completely ad-hoc printer and parser for config files, which have different assumptions. Some allow comma-separated entries in values. Some space or tabs are significant. Varying comment characters. Varying support for multi-line entries. Varying support for quoted strings. Varying support for unicode. Some are key/value, some are section based. Arbitrary special punctuation abounds.

It's a fundamental, unstandardized mess.

From the perspective of just a single program, then fine, it does what it needs to and its individual text formats are human-understandable, and its code is quickly banged together to do what it needs with it.

From an ecosystem perspective, it's a complete failure of usability and _interoperability_, which is the entire point of Unix philosophy in the first place!

Humans aren't the only ones reading & writing config files: Software needs to do it, too, be it applications or automation scripts. Again, text is a horrible substrate for compositing software functionality.

Re: The Collapse of the Unix Philosophy

#196

Post by JoshMnem »

ChuckMcM wrote: post #156

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…

Copying an .editorconfig in every new project solves any problems with remembering to use tab characters.

Re: The Collapse of the Unix Philosophy

#198

Post by fnj »

czep wrote: post #164

A lot of the author's criticisms are about UNIX utilities not gracefully handling filenames containing special characters. But seriously, who puts a newline in a filename? Instead of wasting time writing scripts that meticulously handle all possible edge cases, I'd much rather fix whatever broken process is putting control characters into file names.

"Utilities" should not have to gracefully handle troublesome filenames, each one re-inventing the wheel.

If the system as designed accepts almost literally any characters in pathnames, it doesn't make a lot of sense to complain about people using "naughty" (troublesome) characters in pathnames they create.

It would have made a heck of a lot more sense to have disallowed stupid characters (all white space and control characters at a minimum) from the outset. However, changing it at this point is pretty impractical.

Of all the criticisms of UNIX, the singular one that strikes me as valid is the way that it accepts unquestioningly insane characters in pathnames. I would also maintain that case sensitivity in pathnames and a lot of other places is also a human interface error. It is arguable, and a matter of taste, but I find it obtuse. You should be able to "say" pathnames. The necessity for circumlocutions like "Big-M makefile" is offensive.

I'm one of the biggest fans there is of UNIX and C and the Bourne shell and derivatives, but recognition of weaknesses and flaws in those you love is not weakness; it is wisdom.

Re: The Collapse of the Unix Philosophy

#199

Post by TeMPOraL »

flukus wrote: post #129
richardwhiuk wrote: post #42

Earlier quoted context omitted.

search?

Search what? File names? File contents? Users? Machines?

You could say the same about "mv". Move what? Files? File names? File parts? Users? Machines? Screens?

There's always some default subject implied for every command name. For "find" it is files, for "search" it could have been text.

Re: The Collapse of the Unix Philosophy

#200

Post by nickpsecurity »

pjmlp wrote: post #123
michaelmrose wrote: post #111

Earlier quoted context omitted.

What do you mean by unix in this context? Everything save for windows bears a strong kinship with Unix and every OS is more than capable of running additional runtimes and frameworks beyond C.

UNIX and C are symbiotic, regardless of whatever runs on top, only POSIX and C are common to any UNIX. Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.

It was an OpenVMS derivative wiyh code copied or clean-slated against a modified form of its behavior. However, I heard the networking stack was from BSD.
Post reply on HN