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

401–410 of 616 posts

Re: The Collapse of the Unix Philosophy

#401

Post by tnone »

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…

You know that thing about how old ideas in science can only really be replaced when their supporters die?

Unix greybeards, this is about you.

Re: The Collapse of the Unix Philosophy

#402

Post by dredmorbius »

atombender wrote: post #280
Analemma_ wrote: post #10

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…

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…

"Each tool does just one thing well" doesn't mean "just one tool does one thing". In fact, ETDJOTW means that interoperable alternative tools -- loose coupling -- is more readily supported. So that, say, you can transparently migrate from unsecured rsh to secured ssh. Actually: you can even gain capabilities, since rsh is (misfeature) limited to the 512 low-numbered ports, and hence, a maximum of 512 outbound connections. SSH has no such limitation, and can scale far higher as a management tool.

(That bug, and option, was what finally convinced one old-time shop to swap in SSH for RSH for such tasks, after I identified the problem and the solution.)

A better example would be "one tools" that do many things. Rob Pike suggested Perl, though IMO that's kind of foolish: Perl is Yet Another Programming Language, and programming languages, rather by design, tend to do multiple things (not always, or not always easily: see sed as an example of both caveats -- text replacement or branching code).

Other examples are generally nexus points of complex interactions. Editors (most especially Emacs). Email management (communications protocols, format protocols, ties to DNS, anti-spam, filtering, remote-access (POP and IMAP), extensions, authentication (at various levels), encryption (at various levels). The problem domain is complex, so the tools are complex.

The tool you're very likely using right now to read this would be another case in point: the Web browser. Not just for CERN any more.

Re: The Collapse of the Unix Philosophy

#403

Post by rlucas »

pcwalton wrote: post #379
bad_user wrote: post #368

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

In finance we call the driver of this "survivorship bias."

IOW, your contention is true/truthy if you ignore the fact that there is a large selective pressure weeding out the "not better" new things.

Re: The Collapse of the Unix Philosophy

#404

Post by rlucas »

pcwalton wrote: post #379
bad_user wrote: post #368

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

In finance we call the driver of this "survivorship bias."

IOW, your contention is true/truthy if you ignore the fact that there is a large selective pressure weeding out the "not better" new things.

Re: The Collapse of the Unix Philosophy

#405

Post by aktau »

pjmlp wrote: post #369
derefr wrote: post #157

Earlier quoted context omitted.

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

Where was that, if I may ask?

Re: The Collapse of the Unix Philosophy

#406

Post by fragmede »

skissane wrote: post #392
EdiX wrote: post #364

Earlier quoted context omitted.

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…

Another option is to check what stdout is hooked up to – if it is hooked up to a terminal output something human readable, if it is hooked up to a pipe output something machine readable like JSON. (Actually, a number of utilities do this terminal-vs-nonterminal check already – e.g. GNU ls with --color=auto). One problem I've seen with this approach in practice, is sometimes you want the human readable output to go to…

Less supports setting options in the LESS environment variable, so if you set LESS='-R' in your .bashrc/whatever, you don't have to pass -R to less. (If you do `jq foo | LESS='' less` for the rare times you need less to not behave that way.)

Sadly, it doesn't seem like jq will read an environment setting to always specific -C

Re: The Collapse of the Unix Philosophy

#407

Post by dredmorbius »

ci5er wrote: post #272
bcantrill wrote: post #73

Earlier quoted context omitted.

Thank you for posting this here; I absolutely love that anti-foreward, and it was life-changing for me in that it offered shelter to those of us who were defending Unix during a very, very dark time (namely, the mid-1990s). I have also (shamelessly) cribbed dmr's beautiful closing metaphor of a fecal pie and its "undigested nuggets of nutrition" -- it seems to just describe so much that is not entirely devoid of valu…

How were the mid-90s a dark time for Unix? Every engineers desk at every place I worked and every d/c I deployed to, it was the the only option (I avoided the AS-400, workhorse that it may well have been). Now, which Unix (HPUX, Solaris, AIX, IRIX) caused some angst, depending on the use-case...

Unix was under assault from various sides.

The vendors were fighting amongst themselves for supremacy. Take a look at Larry McVoy's "Free Unix" whitepaper.

https://www.landley.net/history/mirror/unix/srcos.html

IBM had developed OS/2, but was unable to effectively market it, in large part due to the intransigence of its development partner, Microsoft, who had other designs.

Microsoft was of course pushing Windows NT as the full and total replacement for Unix at the mid-server level. I'd actually bought that as my own first personal computer OS, and found it utterly and totally inadequate. Installing Redhat from a bookstore CD started me on my path (though I'd previously used Unix at uni and various jobs).

AT&T were busily suing the crap out of BSD over 1-800-ITS-UNIX, and losing, but setting back both commercial and BSD Unix by about 4-5 years.

Linux emerged during this period under constant FUD assaults by Microsoft, most of the mainstream Unix vendors, and pretty much everyone else.

And Apple was very much in its Dark Age, with OSX (Now MacOS) not due for release until 2002.

Unix was in use, especially in technical shops: scientific, software design, areospace, chips, etc. But it was deprecated in much of the corporate world over mainframes, minis (I cut my professional teeth on VMS), and early Microsoft variants. AS/400 was more an industrial and controls system.

And yes, proliferation of somewhat incompatible Unix variants (and how and/or where you installed the GNU toolchain on same) was another question.

Re: The Collapse of the Unix Philosophy

#408

Post by rwallace »

harel wrote: post #185

He lost me right at the beginning, with "I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself).". This is the OS equivalent of a Call of Duty teenage online player on XBox live.

Well it's a true statement, even if made in an irascible way. If you're going to insult the guy, at least wait until he makes a false statement.

Re: The Collapse of the Unix Philosophy

#409

Post by dredmorbius »

ci5er wrote: post #279
whack wrote: post #125

Earlier quoted context omitted.

As an hobbyist blogger, I can perfectly empathise with why the author wrote that. People love to crap all over a blogger who dares to post his thoughts on a private blog, without first subjecting it to PhD-thesis-level scrutiny. This really gets on my nerves for the same reasons that engineers get pissed off when they decide to open source a pet project and suddenly start getting "URGENT ASAP" feature requests from e…

I stopped posting code from side-projects I was done with, when it started taking on a maintenance life of its own, and getting angry emails. There was a simplicity of the time when you could put a tarball on an FTP server and post the path to the appropriate Usenix group: "Here's a tarball. Have at it. Or don't."

Corollary to Gresham's Law of Tarball Drops.

Re: The Collapse of the Unix Philosophy

#410

Post by jwilk »

ChuckMcM wrote: post #260
ploxiln wrote: post #241

Earlier quoted context omitted.

If you think about Makefile syntax being an earlier member of the same family as Python, the major difference is that tab may have been a more ubiquitous indent convention at the time (but I really don't know). I still prefer to indent C with tabs, and I'm not the only one. It's really not hard to handle tabs well, as a code editor or as a programmer. You can view them as whatever width you like. You can have marked…

One of the nice thing about indenting with actual tab characters is that you separate the notion of 'indentation' from the actual indentation. I set my tab stops to 4 which tightens the code, others set it to 8, still others set it to 2. If the code has tab characters it just works, if the code has spaces there is no way to have your most comfortable indentation level be used.

https://twitter.com/__apf__/status/827964865012649984
Post reply on HN