Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

381–390 of 616 posts

Re: The Collapse of the Unix Philosophy

#381
post #49

"We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy." Rob Pike 2004, h…

> We really are using a 1970s era operating system ...

Try and read it this way:

"We really are using a 1970s era operating system ..."

Re: The Collapse of the Unix Philosophy

#382
post #270

Earlier quoted context omitted.

I wrote my own version of Make for VAX/VMS and MSDOS, back in 1983 or so. I hated the tab mechanism of the Unix make, so I didn't use it, and none of my users (of which there were apparently thousands) ever complained. I got a few "thank you"s for it. TAB was a stupid choice even in the 1970s.

Tab are actually more eco-friendly than space. Just think of the energy lost sending 4 characters instead of 1 in every uncompressed json/xml actually moving around because lazy people don't mind suppress them before sending it over the network...

and imagine how annoying it gets when you are punching a punchcard.

Re: The Collapse of the Unix Philosophy

#383
> Let’s say we need to delete a file on host a@a. The name of the file is in a variable A. How can we do it?

> [...]

> Anyway, the correct answer is: `ssh a@a "rm -- $(printf '%q\n' "$A")"`

In zsh it's just `ssh a@a "rm -- ${(q)A}"`.

Re: The Collapse of the Unix Philosophy

#384
post #318

Earlier quoted context omitted.

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…

I agree with a lot of what you wrote. It's true that there is a "keep it for the elite" mindset in the back of many programmers' mind. For years at forums I've seen that while I tried hard to explain basic concepts to newbies, others were happier with the RTFM answer. Still I'm not so sure that UNIX (or programmers) is the source of it. I started with DOS (later Windows) and TP (later Delphi) so please don't think I'…

I'd guess that much of this depends on who's writing the software. FOSS was (and still is to a great degree) driven by "nerds" in their spare time. If there's no Steve Jobs that smacks programmers about for neglecting the user experience for non-technical users, it won't make much progress. At other places (say Redhat) there's no big need to focus on non-technical users for business reasons when it comes to much of development. And so on and so forth.

If you can accredit Apple with one thing, it would be that they got this mainly right.

When it comes to Windows... I guess that's the result if one main player has a de facto monopoly over a certain software space. That, and "legacy reasons". It's like Adobe who couldn't even get their hotkeys merged between various of their big applications.

Re: The Collapse of the Unix Philosophy

#385

Earlier quoted context omitted.

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

> Besides, who is to tell that the newer design will be better? 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().

Cryptography benefits mostly from huge computing resources we have today and fundamental advances (math). Current crypto algorithms were impossible/impractical with hardware from just few decades ago. Yet we still suck at designing crypto systems.

Re: The Collapse of the Unix Philosophy

#386

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…

JSON doesn't have comments so it's a bad choice for human-editable config. YAML doesn't have an end marker so you can never be sure if you've got the entire file. XML is a huge pain to edit by hand if the schema is complicated, and overly verbose if it isn't. None of them are even close to being safe (for example https://arp242.net/weblog/yaml_probably_not_so_great_after_a...). All of those choices fail your "elegance" test.

TOML is my preferred config file language option where I have a choice - https://github.com/toml-lang/toml - but I suspect that suffers a lot of the same problems.

Re: The Collapse of the Unix Philosophy

#387
post #271

Earlier quoted context omitted.

Of note for folks who don't know it, Common Lisp treats pathnames as structured objects. It's pretty nice, although it'd have been even nicer had they more-fully-specified them with respect to e.g. POSIX filename conventions (e.g. is /foo/bar a directory or a file?). UIOP basically fixes all this, and it works.

Yeah. CL's pathnames are a bit confusing to people though, because they came about as a way to handle several different types of file paths from various operating systems which preceded UNIX / POSIX. For those who're interested, there's a pretty good overview of them in Practical Common Lisp[0]. I'll quote the first paragraph of the subchapter "How Pathnames Represent Filenames", which serves as a decent TL;DR: "A pa…

> because they came about as a way to handle several different types of file paths

They also came as a way to handle file paths at all. Generally Lisp prefers other data representations over string representations. The user input (text string) will be parsed into some kind of data.

Re: The Collapse of the Unix Philosophy

#388

Earlier quoted context omitted.

> "The arguments in the article indeed don't have much to say about Unix Philosophy per se - they're just a list of various fuckups and idiocies Unix accumulated for some reasons or others." Right. The title should have been reflective of that "Various idiocies Unix has accumulated to this day" but since the article mentions Unix Philosophy, my point is that the article should have criticised the philosophy and not t…

> And ahead of its time It wasn't ahead of its time. By the time Unix was created, people were already aware of the benefits of structured data. > it automatically takes advance of multiprocessor systems, without having to rewrite the individual components to be multi-threaded. That's orthogonal to the issue. The simple solution to Unix problems would be to put a standard parser for JSON/SEXP/whatever into libc or OS…

There are no problems where you see them.

Most text formats are trivial to parse and space-separated or character-separated is the way to go. It really doesn't help if you enclose shit in parens. (Parens are sometimes a good way to encode trees, though).

    > (:columns :type :permissions :no-links :owner :group :size :modification-time :name)
That format doesn't solve any of the problems you mention. The problem is that it's hard to agree what data should be inside, not how you encode it.

    > ls | filter ':modification-time  find :name LIKE ".git%" | select (:name :permissions) | format-list > git_perms_audit.log
    find -name '.git*' -printf '%m %f\n' > git_perms_audit.log
Use 0-separated if you care that technically filenames can be anything (except / and NUL). Or say "crap in, crap out". Or assert that it's not crap before processing it.

> Hell, you could display the usual Unix "ls -la" table for the user trivially too, but you wouldn't have to parse it manually.

You don't parse "ls -la". You just don't.

> BTW. This is exactly what PowerShell does (except it sends .NET objects), which is why it's awesome.

Powershell is an abomination, and because it encourages coupling of interacting programs it will never be as successful as the Unix model. There will never be the same variety of interacting programs for very practical reasons.

Re: The Collapse of the Unix Philosophy

#390
post #148

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.

Being able to use the same syntax for code and data is no small thing. This aspect alone puts it above JSON. That, and for most LISPS, S-expressions have a broader vocabulary than JSON (symbols, complex numbers, etc.).

JSON also has hash tables (which they confusingly call “objects”), which sexps do not. One may argue that one is or isn’t slightly better than the other, but the point was that they are very close.
Post reply on HN