A cool Unix video from the 70's

21 hours ago, spivonious wrote

The whole "everything's a file" paradigm is appealing.

The whole "everything's a file" is one of the most fundamentally broken aspects of Unix.

@AndyC: In what sense? Is it a good idea badly implemented or just a bad idea?

Maybe the emphasis on pipelining made Unix too much of a batch processing system and did not work well with GUI apps.  Do Linux apps have message loops?

@fanbaby: It's just a bad idea. It starts off seeming to work, but then you find that for a lot of things file semantics just aren't really a particularly good fit. At that point, however, you have to go down the "Well I only have a hammer, so this problem is just going to have to be a nail" route of trying to fudge things.

23 minutes ago, SteveRichter wrote

Do Linux apps have message loops?

X Window apps, which is what most Linux GUI apps are, have event loops, though they are usually implemented by whatever toolkit a particular app uses.

@AndyC:

It's more accurate to say "everything is a file descriptor" instead of "everything is file". For example, sockets are file descriptors, even though they may not be directly exposed in the file system (they may be in Linux, I'm not sure). I'm interested to know in what cases this design fails.

And it looks like Channel 9 exploded.

That was an interesting video.  The late sixties was an amazing time to be working in the tech industry ... Bell Labs, the other national labs, NASA, the tech universities, etc.  It was such a different environment (fostering technology development) compared to our "service economy" approach today.

The video also makes it apparent how dated the UNIX design is.  Many of the UNIX fundamentals (everything is a file stream, pipe all your data around between snippets of code, scripting everything together) made a lot of sense and solved a lot of problems in the environment of the late sixties -- when everything was text based and command driven, and all computer users were trained technical users.  Those concepts of computing don't fit well into modern computing -- GUIs, events, non-technical users, etc.  UNIX (and LINUX which followed the same model almost exactly) has tried to adapt by patching things on here and there, but that has produced a system that is still really suitable only to technical users that are largely working the same way they did three or four decades ago.  (I admit that I fall into that category at times.)  For the average user, it still ends up being clumsy and awkward.  Certainly Windows has its crusty corners too.

I guess a half century down the road it's time for someone to start with a clean sheet and build a modern OS.  Lots of people are throwing ideas around out there (like MSR).  We'll see if anyone is willing to really make the leap and build a product.  MS will probably just evolve Windows.  Linux (i.e. Linus) has little reason to start over.  Apple?  Who knows?  There aren't many little guys willing to compete with the big players anymore.  You invest a lot into a project and get sued or swallowed.

5 hours ago, Bass wrote

@AndyC:

It's more accurate to say "everything is a file descriptor" instead of "everything is file". For example, sockets are file descriptors, even though they may not be directly exposed in the file system (they may be in Linux, I'm not sure). I'm interested to know in what cases this design fails.

My main issue is that it seems there's a lot of information that is only exposed as a text file in the /proc file system. And writing code to parse those text files is cumbersome, and both slower and more likely to break in the future (if the format of the file changes) than an API call would've been. I'll admit that it's nice that this info is intrinsically available in every environment (like Mono or Java) without having to find some way to do system calls, but when I'm writing a C(++) program, why does the kernel (also written in C) have to generate a text file only for me to immediately parse it back?

8 hours ago, ryanb wrote

[...]

The video also makes it apparent how dated the UNIX design is.  Many of the UNIX fundamentals (everything is a file stream, pipe all your data around between snippets of code, scripting everything together) made a lot of sense and solved a lot of problems in the environment of the late sixties -- when everything was text based and command driven, and all computer users were trained technical users.  Those concepts of computing don't fit well into modern computing -- GUIs, events, non-technical users, etc.  UNIX (and LINUX which followed the same model almost exactly) has tried to adapt by patching things on here and there, but that has produced a system that is still really suitable only to technical users that are largely working the same way they did three or four decades ago.  (I admit that I fall into that category at times.)  For the average user, it still ends up being clumsy and awkward.  Certainly Windows has its crusty corners too.

[...]

1. You are aware that macs run a form of unix, are you?
2. The command line isn't for the average user, true, but that doesn't mean it's dated. I read that Microsoft is planning a command line only version of windows (!)
3.  Same for pipes. If i'm not mistaken, powershell tries to be shell 2.0. It's "pipes done right" with something else flowing in them instead of text (facepalm)

3 hours ago, Sven Groot wrote

*snip*

My main issue is that it seems there's a lot of information that is only exposed as a text file in the /proc file system. And writing code to parse those text files is cumbersome, and both slower and more likely to break in the future (if the format of the file changes) than an API call would've been. I'll admit that it's nice that this info is intrinsically available in every environment (like Mono or Java) without having to find some way to do system calls, but when I'm writing a C(++) program, why does the kernel (also written in C) have to generate a text file only for me to immediately parse it back?

First, isn't the proc filesystem nice? It came from Plan9. Second, Unix proved to me that the cost of converting things to text and from text is far outweighed by the benefit of, like you said, using a universal format. Not sure what to do if that creates a bottleneck in your program though.

@Bass: "Actually Linux was one of first UNIX-like OSes that was explicitly designed for PCs"

I seem to recall having an early IBM PC running SCO-Xenix... ?

@elmer: It originated as Microsoft Xenix, for the record, and it ran on pretty much anything that moved. Including the PDP-11.

5 hours ago, fanbaby wrote

*snip*

 Second, Unix proved to me that the cost of converting things to text and from text is far outweighed by the benefit of, like you said, using a universal format. Not sure what to do if that creates a bottleneck in your program though.

It's not the runtime cost, it's the development cost of having to continuely re-invent the wheel to parse what was structured data that has been forced into a text file back into structured data again, dealing with all the idosyncrasy that entails. Even sticking to a relatively similar concept of a 'universal format', something like Powershell proves it can be done infinitely better. 

@AndyC: I think you misconstrued me. The universal format is text.

That sounds extremely inefficient to me. How does this work with, say, image files or audio files? How would you implement something like ReWire that allows different audio applications to share audio and MIDI streams in realtime?

I guess back when they thought this was a great idea, computers weren't very powerful anyway so the datasets they worked on were probably very simple and small (mostly text-based anyway).

I realize today these file descriptors can be a byte stream (like a socket) but the idea that everything can be converted to/from text just doesn't work today.

I think even streaming bytes isn't enough. Sometimes you need objects so that you can query just the properties on it that you are interested in. How do you get just the size of a bitmap if the only option is to stream the whole thing? For very large images this is inefficient because now the image needs to be duplicated in multiple places.

@BitFlipper: While I am aligned with unix, that text is the preferred format for data, no one means all data formats.

Specifically i like the fact that to get info on running processes on some unicies you just read a text file. This involves the conversions binary=>text=>binary [IT JUST OCCURRED TO ME THAT SO DOES THE WEB, BTW] but who cares.

EDIT: It's amazing that so many ideas from the creators of Unix endured this long. 

2 hours ago, fanbaby wrote

@AndyC: I think you misconstrued me. The universal format is text.

Please define "text".