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…
The Collapse of the Unix Philosophy
461–470 of 616 posts
Re: The Collapse of the Unix Philosophy
#462Earlier 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).
Re: The Collapse of the Unix Philosophy
#463Earlier 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…
Re: The Collapse of the Unix Philosophy
#464That 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.
Re: The Collapse of the Unix Philosophy
#465My 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.
Re: The Collapse of the Unix Philosophy
#466Earlier 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…
Text representation is a good idea regardless of whether you pipe or not.
Re: The Collapse of the Unix Philosophy
#467Earlier 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…
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
#468Earlier 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? :)
Re: The Collapse of the Unix Philosophy
#469Re: The Collapse of the Unix Philosophy
#470Earlier 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…
> 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.