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

241–250 of 616 posts

Re: The Collapse of the Unix Philosophy

#241

Post by ploxiln »

rootbear wrote: post #212
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…

I had much the same reaction. I learned Unix on a PDP-11 running sixth edition AT&T. I was also using the University's UNIVAC 1108 and the elegance, simplicity and orthogonality of the Shell vs the EXEC-8 command language was a joy to behold. Sure, there is much about Unix that could be better and I sometimes regret that Plan 9 didn't succeed more. But it's like Kirk said to Saavik, "You have to learn WHY things work…

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 to distinguish from spaces (e.g. vim's "set list"). They've been around for longer than you have so there's no good excuse for forgetting about them.

Re: The Collapse of the Unix Philosophy

#242

Post by opportune »

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…

I don't think the terminal-based multi-user time sharing model maps poorly to servers, at the very least. In fact if you're going to pick one model for the general class of servers to run under, that's probably going to be the most versatile. Sure supercomputers and data centers may stand to benefit from a model that ignores all the multi-user features and such, but in architectures where each server is acting at least semi-autonomously (i.e. not under the control of what is essentially some distributed operating system such as Yarn, SLURM, etc.) I think you'd struggle to come up with a better model. This shouldn't be surprising as this is basically the exact use case that UNIX was built for.

Re: The Collapse of the Unix Philosophy

#243

Post by flukus »

nickpsecurity wrote: post #192
flukus wrote: post #122

Earlier quoted context omitted.

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

Is there a description/examples of these anywhere? Combex doesn't provide a lot of info and I couldn't find anything on PowerBox.

From the description of Combex (http://www.skyhunter.com/marcs/capabilityIntro/):

> Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.

In reality, users will get sick of being prompted every 30 seconds and learn to automatically approve every request. Capability security works well in theory, but I've never seen an implementation that works well in practice.

Re: The Collapse of the Unix Philosophy

#244

Post by kking50 »

whack wrote: post #125
wyclif wrote: 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.

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 respectfully disagree with that last part. IMO it's your moral obligation as a distributor of information to, to the best of your ability, ensure its' truth and validity.

I'm not saying it has to be PhD-thesis-level, but if proven wrong you are morally obligated to update the information or remove it. Otherwise you are spreading false knowledge. This doesn't apply to opinions ofc (the bulk of private blogging).

Screw entitled users though, they should fix it themselves :)

Re: The Collapse of the Unix Philosophy

#245

Post by chmaynard »

pjmlp wrote: 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…

Further evidence that Rob Pike is a second-rate engineer and a lousy writer.

Re: The Collapse of the Unix Philosophy

#246

Post by diminoten »

dawidw wrote: post #189
squeaky-clean wrote: post #162

Earlier quoted context omitted.

it's a joke. Last sentence of the article is > The provocative tone has been used just to attract your attention.

That's a pity because of that tone I abandoned reading after few sentences and did't go to last sentence.

...and the world continued to spin.

There's irony in people being insulted by arrogant tone and loudly proclaiming they stopped reading something.

Re: The Collapse of the Unix Philosophy

#247

Post by tomc1985 »

SFJulie wrote: post #216
eikenberry wrote: post #142

Earlier quoted context omitted.

Any free software OS can meet his requirements as they all are transparent to anyone with the time to learn, just like the older bikes. The problem with modern bikes is that all the advanced tech is proprietary and you have no way of understanding it or tinkering with it. IMO you can take any modern distro and strip it down to something understandable. It just takes some time to learn how to strip it down and how wha…

Just remove systemd that is looking like an electronic injection that now requires 4Gb of RAM and a full OS to work and screaming for more.

We run systemd on 512mb celerons no problem...

Re: The Collapse of the Unix Philosophy

#248

Post by em3rgent0rdr »

TeMPOraL wrote: post #187
em3rgent0rdr wrote: post #130

This whole article is a bunch of strawman arguments. It points out historical mistakes by unix developers, but those mistakes aren't inherent to or a result of the Unix Philosophy: (1) Write programs that do one thing and do it well. (2) Write programs to work together. (3) Write programs to handle text streams, because that is a universal interface.

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. As for Unix Philosophy, the point (3) in your summary is something that's a) dumb, and b) back when it was created, they already had better solutions. Passing text streams around is a horrible idea because now each program has to hav…

> "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 the practice.

> "Passing text streams around is a horrible idea because now each program has to have its own, half-assed shotgun parser and generator, and you have to glue programs together with your own, user-provided, half-assed shotgun parsers, i.e. calls to awk, sed, etc."

But this has actually proved to be very useful as it provided a standard medium of communication between programs that is both human readable and computer understandable. And ahead of its time since it automatically takes advance of multiprocessor systems, without having to rewrite the individual components to be multi-threaded.

> "(3) makes you programming with a dynamic, completely untyped language which forces each function to accept and return a single parameter that's just a string blob. No other data structures allowed."

That may be a performance downside in some cases, but the benefit of having a standard universally-agreeable input and output format is the time it saves Unix operators who can quickly pipe programs together. That saves more total human time than gained from potential performance benefits.

Re: The Collapse of the Unix Philosophy

#249

Post by rangibaby »

mulmen wrote: post #230
sedachv wrote: post #176

Earlier quoted context omitted.

> It will be in a junkyard within ten years though. I won't be able to find those sensors in a few years. Not true. You will be able to get an aftermarket ECU that can just ignore the sensors and run in open-loop mode. That will be exactly the same as running with carburetors: fixed fuel/air ratio that is almost always wrong. This is also the failure mode for OBDII cars - sensor failures lead to the ECU running in op…

Maintenance "headaches" are part of the appeal of old bikes. It's much easier to learn how an internal combustion powered vehicle works on an old Honda bike than a new one, or on a new car. Compared to other bikes of their day these are very simple to maintain and they were designed from the start to be kept running by the average person. It really depends on what you are looking for in a bike. If enjoying turning a…

I used to share your opinion, but hours of searching for no longer-made parts and obscure wrench sizes and other tools that often simply don't exist anymore cooled my enthusiasm somewhat (fixing 1960s camera lenses)

Re: The Collapse of the Unix Philosophy

#250

Post by ChuckMcM »

rootbear wrote: post #212
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…

I had much the same reaction. I learned Unix on a PDP-11 running sixth edition AT&T. I was also using the University's UNIVAC 1108 and the elegance, simplicity and orthogonality of the Shell vs the EXEC-8 command language was a joy to behold. Sure, there is much about Unix that could be better and I sometimes regret that Plan 9 didn't succeed more. But it's like Kirk said to Saavik, "You have to learn WHY things work…

I think it is this ambiguity of tab that was the source of confusion. Certainly on DEC machines at the time, when you typed 'tab' in and editor that was inserting text it was because you wanted an ASCII TAB character in your text. What was more, the program could just echo the TAB character to the terminal you were using and the terminal would "do the correct thing" for displaying that tab. Back in the 90's when 'model/view' controllers were the rage it was couched as separating presentation from the semantics.

The challenge came when there were devices which operated incorrectly when presented with a TAB character or confused command data with actual data. That became the "killer" issue when computers started substituting for typewriters. Because a typist knows that if you hit the tab key the carriage would slide over to the next tab stop that was set on the platen bar, but the paper was "all spaces". When you try to emulate that behavior in a computer now the TAB becomes a semantic input into the editor "move to the next tab stop" rather than "stick a tab in" and "move to the next tab stop" could be implemented by inserting a variable number of spaces.

Computer engineers knew it was "stupid" to try an guess what you wanted with respect to tabs so they wrote a program for formatting text called 'troff' (which had similarities to the program on RSX11, TENEX, and TOPS called RUNOFF.

It is always interesting to look back though, if you had told a system designer in the 70's that they would have gigabytes of RAM and HD displays in their pocket when their grandchildren came to visit they would have told you that people always over estimate how fast change will happen.

Post reply on HN