Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

461–470 of 616 posts

Re: The Collapse of the Unix Philosophy

#461

Earlier quoted context omitted.

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 "elegan…

The issue with all of these, of course, is that in order to get a system running you have to configure multiple "independent" tools, processes and daemons. Think setting up a web application - you have to configure the web application to listen on a certain port/UNIX socket, then configure your web server to go find it. You then need to scale this up across logical servers separated by a network - your web servers ne…

I agree with most of your post, but this is still more complex than just adding a constraints solver and an event processing system. Different things not just depend on each other, they also require different strategies for dealing with failures. Trying to squeeze everything into a single model will not work well. Maybe something like supervision trees for services might solve that, where supervisors for each service are part of the package and handle everything from automatic configuration to failures in any way they need.

Re: The Collapse of the Unix Philosophy

#462
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…

> 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. Which is where they fundamentally break the principle of "doing one thing, and doing it well". Formatting output for user should be a separate step (even if implicitly handled by your shell).

That's one place where I felt like PowerShell was way more UNIX-y than UNIX commands in that many commands are truly orthogonal.

Re: The Collapse of the Unix Philosophy

#463

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…

> 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. Except it is completely unusable for network applications because the error handling mo…

[deleted]

Re: The Collapse of the Unix Philosophy

#464
post #236

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…

IMO, the main takeaway from the article isn't that "those 70's developers lacked imagination", but that UNIX is far from perfect. The author even states that UNIX was amazing when it came out, but that doesn't mean all its ideas make sense today.

"they lacked imagination and like, I feel that we, young people today, like, a new generation, could do better"

Re: The Collapse of the Unix Philosophy

#465

My favorite one “everything is a file”. My GPU has 4 times as many transistors as my CPU, and for parallel tasks, it computes stuff 50 times faster. Just too much complexity for a file, even with ioctl. I think that ideology is the main reason for the current state of 3D graphics in nix and bsd based platforms.

I didn't downvote you, but I'm not seeing the problem here. It's great that we have these fantastically powerful GPUs, which of course don't use text files as their internal representation, but then we have to tell them what to render or otherwise compute, and very often some form of text file is the most effective way to do that.

Re: The Collapse of the Unix Philosophy

#466

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…

> 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. Except it is completely unusable for network applications because the error handling mo…

It's true that error handling with (shell) pipes is not possible in a clean way in general. In shell, the best you can do is probably "set -o pipefail", but that's only in bash. Concurrency with IO on both sides is really hard to get right even in theory.

Text representation is a good idea regardless of whether you pipe or not.

Re: The Collapse of the Unix Philosophy

#467
post #272

Earlier quoted context omitted.

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/400 was more an industrial and controls system.

Really? We used it a lot in payments. But it was paired up with Tandem and/or Unix (AIX, HPUX).

There was certainly a lot of thrashing as mini-computer manufacturers were having their "last hurrah".

Thanks!

Re: The Collapse of the Unix Philosophy

#468
post #457

Earlier quoted context omitted.

I remember people saying Unix was the gold standard of user-hostile operating system. That was well before I met AS/400 and MVS. And then I had contact with a Burroughs A-series and it's appropriately named OS, MCP. OTOH, I love the 3270s.

TRON 's MCP was named after Burroughs', I'm quite sure. Guess who TRON/Alan Bradley was based on? :)

I think it's for Alan Kay. Bonnie MacBird is his wife.

Re: The Collapse of the Unix Philosophy

#470

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…

all of your arguments here - pro or con - are reflections of philosophy and have nothing to do with computers

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

this presumes programming (which itself is simply logical thinking) is something obscure and 'scary'. Elementary school computer literacy courses in the mid-late 80s/ early 90s routinely taught more programming know-how to adolescents than college graduates have today. Is this because kids are stupid? or has the goal of curricula been relegated from 'high level understdanding and knowledge' to 'economic productivity within the present system'?

> The real effect of UNIX has been to keep programming professional and to keep user-friendly concepts well away from commercial and academic development.

really? is that why UNIX minis rapidly displaced mainframes in the late 70s/early 80s, with major advances primarily being derived from the cross-compatibility of most unix flavors being shared within industry and academia? Or is this another argument towards 'economic productivity within the current sytem' ?

> Programming could have been made much more accessible, and there's consistent evidence from BASIC, Hypercard, VBA, the HTML web, and even Delphi (at a push) that the more accessible a development environment is made, the more non-developers will use it to get fun and/or useful things done.

a) by evidence, you're referring to cross-linked excel spreadsheet nightmares? b) by evidence, why does this not include all of the literally millions of interpreted programs in say shell, awk, TCL, and so on written by unix users in professional settings across time? c) compare shell scripting to batch scripting. seriously. Also, the web was invented on Unix. d) See also use of lisp, etc. in the 80s for pretty much the same things

I argue that the issues you are speaking about here primarily derive as a result of the workstation Unix market focusing on the higher end, while the low end grew on the PC side - which has nothing to due with the Unix tradition itself, which due to licensing issues with AT&T, etc. was relegated to somewhat obscurity during the heavy capitialization of the PC market of the 80s.

> UNIX has always worked hard to be the opposite - an impenetrably hostile wall of developer exceptionalism that makes the learning curve for development so brutally steep it might as well be vertical.

Really? Is that why, from nearly day 1, the entire system was distributed on a single tape with complete binaries, sources, and manual pages contained on the same, self-hosting installation?

Again - while lesser users will use their knowledge of the system as some narcissistic playing card, this is their own personality flaws being interjected into the philosophical difference I mentioned previously (achieving knowledge vs brutish ad-hoc productivity)

> UNIX people like to talk about commercial walled gardens as if they're the worst possible thing. But UNIX is a walled garden itself, designed - whether consciously or not - to lock out non-professional non-developer users and make sure they don't go poking at things they shouldn't try to understand.

Again, I think this supposition is derived from the growth of the commercial Unix market, which deliberately split source code and documentation into tiny little fragments, only some of which could be even attained in the first place, and could only be run on proprietary hardware. Unix itself (the portable software system) grew in a mostly obscure, tangential lineage that was then 'walled off' from naive end users through marketing efforts of proprietary vendors. See also BSD UNIX.

> Opaque documentation, zero standardisation for command options, and ridiculous command name choices all make UNIX incredibly user hostile.

yes, things are inconsistent. but that is because the system grew organically. I give much kudos to VMS for being very solid and coherent in this regard - but that was just as much a walled garden as anything else, and still is (though interesting things could still come from the OpenVMS company)

nothing precluded anyone from bolting on a coherent addon to the unix base, and indeed many did. However they failed because unix is not a product, but a product of organic human culture -

and so ones qualms with unix are really ones unresolved qualms with human endeavor itself.

Post reply on HN