Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

321–330 of 616 posts

Re: The Collapse of the Unix Philosophy

#321

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. 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 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 model is broken (exit status? stderr? signals? good luck figuring out which process errored out in a long pipe chain) and it is almost impossible to get the parsing, escaping, interpolation, and command line arguments right. People very quickly discovered that CGI Perl with system/backticks was a very insecure and fragile way to write web applications and moved to the AOLServer model of a single process that loads libraries.

Re: The Collapse of the Unix Philosophy

#322
post #125
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 can relate too. I once started a blog post with "if you don't like [it], go jump in a lake."

I was envisioning people nit-picking the lack of formality, when it was merely an enthusiastic, from-the-hip post.

A day later I realized that wasn't the best way to start things off with, and toned it down. But I get where he's coming from. And I'm grateful he took the time to write it. It was an interesting read.

Re: The Collapse of the Unix Philosophy

#323

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…

Newer than 1990 doesn't mean fuel injected and sensors out the wazoo. I have a 2001 Bandit and it's brilliant, same power and fuel economy as the current model and pure old fashioned air cooled carbie goodness. Nearly 70k kms and the mechanic reckons it'll be good for as much again.

Re: The Collapse of the Unix Philosophy

#324

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…

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest,…

Source: The Art of Unix Programming

Re: The Collapse of the Unix Philosophy

#325
post #211

Earlier quoted context omitted.

"Doctor, it hurts when I do this." "So don't do it." The problem with filenames is just a symptom of the biggest problem of UNIX conventions - passing around unstructured text. Filenames should have one well-defined format (AFAIR kernel allows pretty much anything but the NULL character). That's it. For most applications, filenames should be opaque data blobs compared for binary equality. But because we're passing ar…

When the design was made, no one was considering pathology. We were all too invested in the wonder of making it all work to worry about people screwing around in crazy ways, let alone purposeful attacks. As long as everyone recognized that putting certain characters in pathnames was counter-productive, things worked fine. Nobody ever dreamed of putting a space character in a filename when they all came from a CLI bac…

When the design was made, no one was considering pathology. We were all too invested in the wonder of making it all work to worry about people screwing around in crazy ways, let alone purposeful attacks

Shortly after timeshare systems were created, people were thinking about security.

Re: The Collapse of the Unix Philosophy

#326

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…

> And ahead of its time It wasn't ahead of its time. By the time Unix was created, people were already aware of the benefits of structured data. > it automatically takes advance of multiprocessor systems, without having to rewrite the individual components to be multi-threaded. That's orthogonal to the issue. The simple solution to Unix problems would be to put a standard parser for JSON/SEXP/whatever into libc or OS…

[deleted]

Re: The Collapse of the Unix Philosophy

#327

Earlier quoted context omitted.

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

I'm sad that 512mb is now considered a small amount. I've got a couple of systems in my drawer that have <128mb.

Re: The Collapse of the Unix Philosophy

#328
post #46
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…

Hence why UNIX on mobile is a Pyrrhic victory, as iOS, Android, ChromeOS rely on Objective-C, Java and JavaScript runtimes and their respective frameworks, just with good enough support from POSIX, that could be replaced by what is expected from any ANSI C implementation.

There is no Objective-C "runtime". (Well, there sort of is, but it's just a library, not a heavy-handed thing like you're thinking of). Unlike Android, iOS apps are just normal compiled ARM machine language binaries executing natively.

Yes, you have to use their APIs in order to write graphical programs, but the same is true on any OS with a GUI system.

It's possible to write iOS apps in pure C if you want to. Sure, that'd be a pain, but it's possible. Less painful and actually decently reasonable would be to write all the GUI-specific stuff in Objective-C and any other logic in pure POSIX-conforming C or C++, since you can mix all those languages freely in a project.

Re: The Collapse of the Unix Philosophy

#329
post #240

I read once that the dd command (which stands for convert and copy) was not named cc because the compiler was already called that so they used the next letters in the alphabet. NAME dd - convert and copy a file

No, it came from data definition on OS/360 JCL which is the reason why it has a different syntax than the other utils.

Re: The Collapse of the Unix Philosophy

#330
post #154

I think it's very telling that the author consistently refers to directories as "folders". All of UNIX makes perfect sense if you are using UNIX for UNIX. If you're doing other things, like abstracting to "folders" and so on ... I am open minded and can see where it starts to fall apart a bit. But I use UNIX for the sake of UNIX ... I am interested specifically in doing UNIX things. It works great for that.

Asking not to make a point but because I genuinely don't have any clue: what is the distinction in your mind between a "directory" and a "folder", other than that latter term is more widely used in the Windows community?
Post reply on HN