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

501–510 of 616 posts

Re: The Collapse of the Unix Philosophy

#501

Post by dredmorbius »

ci5er wrote: post #467
dredmorbius wrote: post #407

Earlier quoted context omitted.

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!

I've not played with the AS/400s myself, but understand they saw a lot of use in industrial and process applications.

There may well have been others. I'm not claiming any particular expertise, just general knowledge, from the industry. And being old.

Re: The Collapse of the Unix Philosophy

#502

Post by contras1970 »

vacri wrote: post #58

> [shell] It becomes especially bad when we try to develop in it, as it’s not a full-fledged programming language. Who the hell 'develops' in shell? It's a glue language, not a development language. I've never heard anyone say "We're a shell shop".

just like you never hear a carpenter say they have a saw-and-hammer shop. languages are tools, not identities.

anyway, is something like [this] result of development or gluing things together?

[this] https://github.com/roman-neuhauser/haveopt/blob/master/s/hav...

Re: The Collapse of the Unix Philosophy

#503

Post by marcosdumay »

rbanffy wrote: post #428
sowhatquestion wrote: post #363

Earlier quoted context omitted.

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

> wonder if we can do better today Cough... systems... cough... We can do better. Plan 9 existed. Apple's Newton has a unique take on data files. AS/400's map all storage to memory addresses giving a single address space for everything. With Smalltalk, applications would just be new classes you import into your system. The key to Unix's success seems to be not doing better, but doing as little as possible while still…

Plan 9 is not "better enough". The other ones had fundamental non-technical problems that hurt their adoption (Plan 9 had those at the beginning too).

Back to Plan 9, you can expect something that is just slightly better than your current options, and that keeps being this way to steadily gain adoption until it's popular. But that requires it being no worse than the current on any popular use case. Plan 9 may have a great architecture (I'm not sure about that anymore), but OSes compete on many different fronts, like portability, performance, software availability...

If the Plan 9 architecture were something amazingly better that solved a lot of problems, you could be sure some people would have adopted it, and then it would start improving on the other dimensions. But it's not. It's better. It will make your life easier. Yet it will bring no order of magnitude change. So, people simply take a deep breath and write (again and again) the 3 or 4 lines of code required to solve their problem in Unix, instead of changing everything.

Re: The Collapse of the Unix Philosophy

#504

Post by gens »

pjc50 wrote: post #479
gens wrote: post #474

Earlier quoted context omitted.

>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 shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought…

XML is nasty, but at least it's nasty in standardised ways. I've definitely worked with worse (e.g. Cadence DEF files). The lag should be regarded as intolerable, but instead it's routine. I shouldn't have to wait for computers like this. Shell is a nice idea, but UNIX should either have banned whitespace in filenames or made the shell handle it properly. It's amazing how many things blow up on encountering a space,…

ftp://ftp.slackware.org.uk/slackware/slackware64-14.2/ChangeLog.txt

Just ctrl+f for "xml". (edit: nvm, only 3 reports are bugs. although the libxml2 report has 3 somewhat serious bugs)

"XML is a well established standard" is usually the reason people choose XML for anything. I guess i would add "Nobody got fired for choosing XML" to the list of such sayings, if i had such a list.

Re: The Collapse of the Unix Philosophy

#505

Post by jstimpfle »

TeMPOraL wrote: post #493
jstimpfle wrote: post #454

Earlier quoted context omitted.

> because every program has to contain its own, half-assed parser for textual data. As I said, name me a format that I can't parse correctly as a Python one-liner. I work as a systems administrator and my scripts (mostly shell, python) don't break. I'm not kidding you. Of course when writing shell scripts (which I think you imply) I need to know how to write non-broken shell scripts (in a clean and straightforward wa…

> As I said, name me a format that I can't parse correctly as a Python one-liner. Sorry, I misread that in your previous comment as "name me a format that I can parse correctly with a Python one-liner, without special libraries". Anyway, the original article contains numerous examples of the issues I'm talking about; scroll to "Let’s begin with a teaser" and read from there. The point being, it's very difficult to co…

> Let’s begin with a teaser. How can we recursively find all the files with \ name in a folder foo? The correct answer is: find foo -name '\\\\'

He doesn't know shell quoting (or has problems with the blogging software). It's '\\' and there is nothing wrong with that (-name accepts a pattern, not a fixed string)

> How to touch all files in foo (and its subfolders)? At first glance, we could do it like this: find foo | while read A; do touch $A; done

No.

     find foo -exec touch {} \;
     #or
     find foo -print0 | xargs -0 touch
These examples only prove that the author is not proficient at shell.

And we are not talking about shell (which does have flaws) but text representation. You still haven't provided the text format I asked for.

> To argue for the OP, consider the case of passwd being parsed on every system call. That is simply sub-optimal.

As you know there are various encoding schemes, but mostly character separated (space, newline, NUL, colon, whatever) or record-oriented (two separator levels, often newline and space/colon/comma.

In most places, only identifiers are allowed ("and" ("there" ("is") ("no" "fucking" "point") "in" ("wrapping" "everything" "in" ("quotes" "and" "parens"))). Just write things like this, and parsing won't be any harder than splitting on whitespace. Was that so hard?

Re: The Collapse of the Unix Philosophy

#507

Post by nickbauman »

sedachv wrote: post #176
nickbauman wrote: post #91

Earlier quoted context omitted.

I love motorcycles too. I've owned many sophisticated bikes: Ducatis with their strange Desmodromic heads. With the ability to dial an exchange of torque to horsepower at the handlebars. Buells with their fuel-in-frame chassis. My current Suzuki even has 4 sensors in the airbox alone. One that measures the air input pressure. One that measures the oxygen level. One that measures the air temperature. Really amazing pe…

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

As it stands, the Suzi's input pressure sensor is malfunctioning (a $200 part where available) and the bike backfires and splutters badly. So I'm not convinced that an open loop mode ECU won't end up with an engine fire or a hole in the piston.

Other folks have mentioned that the mechanical points can be swapped out for a solid state ignition on the CL, closing that loop of maintenance for starters.

Re: The Collapse of the Unix Philosophy

#508

Post by lobster_johnson »

dredmorbius wrote: post #402
atombender wrote: post #280

Earlier quoted context omitted.

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 connect…

That's one interpretation, but it's not really what people mean when they refer to "one tool". The progenitor of the expression is Doug McIlroy:

    This is the Unix philosophy: Write programs that do one 
    thing and do it well. Write programs to work together. 
    Write programs to handle text streams, because that is a 
    universal interface.
Interoperability is part of DOTADIW idea, but it flows from the "one thing": If each tool does one thing, you can compose them using pipes. Of course, interoperability also implies tools can be swapped out, though as with DOTADIW, it's more of a myth than reality, because reality isn't that simple.

Re: The Collapse of the Unix Philosophy

#509

Post by stillsut »

gens wrote: post #474
sowhatquestion wrote: post #363

Earlier quoted context omitted.

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

>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 shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought…

> what the fuck are programmers thinking when writing today's programs

The difference is in the old days, you adapted to computer. Now, computer must adapt to you.

Take a look at MS's latest text-editor program's release notes (https://code.visualstudio.com/updates/v1_10). They have to build a program that accommodates so many different existing must-have features (from a potential users POV), and for each feature, accommodate almost every flavor of configuration that has ever existed for any other text editor whose style the potential user is now "locked-in to". Otherwise user will refuse to adopt.

In the 70's, I assume the audience was a pretty tight knit community of computer engineers, coming from a time of very frustrating tooling where it wouldn't be uncommon to lose a day's work because the 'Save' function failed or something like that. In this environment, you learned the crazy unintuitive keymap for vi and called it a blessing.

Now, you yell at your editor if it doesn't remind you to save your work when you close it. Or you yell at it when it does remind you; too many pop-ups! The point is that user preferences are more fragmented and expectations are higher for features, and willingness to learn details and gotchas of a program are lower, which has created the bloated program for the simple things like text editors.

Re: The Collapse of the Unix Philosophy

#510

Post by pdimitar »

jstimpfle wrote: post #505
TeMPOraL wrote: post #493

Earlier quoted context omitted.

> As I said, name me a format that I can't parse correctly as a Python one-liner. Sorry, I misread that in your previous comment as "name me a format that I can parse correctly with a Python one-liner, without special libraries". Anyway, the original article contains numerous examples of the issues I'm talking about; scroll to "Let’s begin with a teaser" and read from there. The point being, it's very difficult to co…

> Let’s begin with a teaser. How can we recursively find all the files with \ name in a folder foo? The correct answer is: find foo -name '\\\\' He doesn't know shell quoting (or has problems with the blogging software). It's '\\' and there is nothing wrong with that (-name accepts a pattern, not a fixed string) > How to touch all files in foo (and its subfolders)? At first glance, we could do it like this: find foo…

> Author is not proficient at shell

> Partly because shell has some flaws, but more because of the insane amount of broken scripts and tutorials out there.

So what are you saying then? Basically, "git gud"? I am struggling to find your exact argument here. I wonder if you keep saying "it's not broken, you're just using it wrong", or "you must be proficient and if you're not, it's nobody's fault", or what exactly?

The main argument here is IMO that unstructured text which can be parsed with space/tab delimiters in mind is NOT good enough. You say it is. I disagree; I've had numerous cases in my career where any random dev never takes that into account and just throws almost-native-English files into a Linux VM expecting a 1970s system tool to be able to parse it and make sense of it.

Their fault? Absolutely and definitely. But it's the job of the tech to slap you through the wrist if you are not obeying to standards. Computers are not AI and they need protocols / standards. Are there standards in piping things between processes in UNIX/Linux? No.

Then what's the point of technology at all, I ask.

Post reply on HN