BTW: I'm sorry if I'm wasting anyone's time here by introducing non-Microsoft topics, I only thought it would help some of you better understand OSS tools and the community. I used to have two gripes with Microsoft. 1) Silverlight polluting the web, which was the reason I originally came here, and 2) Patent law-suits directed at Linux, Android ans OSS in general. Thankfully only one reason remained.

2 hours ago, fanbaby wrote

BTW: I'm sorry if I'm wasting anyone's time here by introducing non-Microsoft topics, I only thought it would help some of you better understand OSS tools and the community.

My immediate reaction to that is the same as my reaction to Christians trying to 'save' me : I am perfectly well aware of the other points of view, please don't insult me by assuming my choices are based on ignorance.

.Herbie

UNIX was overkill for PCs of the 1980s which had very little system resources. It was originally designed for "mini"computers, which were much larger and more expensive than a PC. Here is a minicomputer.

The 8088 didn't have memory protection needed for Unix.

DOS was CP/M based or derived, so when many ideas from unix had to be grafted in, it caused some friction (drive letters, directory seperator, command line flags seperator ...)

5 hours ago, Dr Herbie wrote

*snip*

My immediate reaction to that is the same as my reaction to Christians trying to 'save' me : I am perfectly well aware of the other points of view, please don't insult me by assuming my choices are based on ignorance.

 

.Herbie

What is this talk about religion??

Oh, i see:

7 minutes ago, AndyC wrote

There's also the small fact that, contrary to what many in the OSS world want you to believe, Unix is not the be all and end all of perfect OS design. [...].

Of course it's not. Plan 9 is.

EDIT: I'm only half joking, it's in its charter

4 hours ago, fanbaby wrote

*snip*

Of course it's not. Plan 9 is.

We all know the one true OS was BeOS.

Edit: And seriously, what is going on at 18:18?

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.

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.

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.

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.

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

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. 

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.

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

7 minutes ago, fanbaby wrote

Text is what HTML, CSS and JavaScript use

So, not universal. Ok.

36 minutes ago, fanbaby wrote

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.

Except that "just read a text file" is actually a rather more involved process, since you have to then try and parse the file, dealing with subtle variations that may exist between versions (or in some cases, just because a user has gone and aliased some of their preferred defaults somewhere). It's a very fragile way of doing things, not to mention inefficient if all you really wanted was a specific bit of data on a very specific process (or set of processes, say all those using more than 5% cpu). Adding something like a trigger that fires when a specific set of events occur is quite an alien concept to Unix because of this, wheras it's a much better and more logical fit in the Windows world.

And it's by no means the only place where the 'everything is a file' type approach starts to break. Even "files" like log files don't fit as well, because you don't really want to deal with them as an actualy file most of the time, you actually want to be able to treat them more as a collection of entries that can be sorted and filtered easily. The Unix model falls back on messing text parsing again. There are also situations like per-user mounts of network volumes (such as SMB shares) that the *nix model really can't handle well, because it simply doesn't gel very well with the idea that everything is represented by files in a consistent hierarchical namespace that doesn't depend on who you are.

Having everything be a file descriptor greatly simplifies the API, instead of having over 9000 syscalls for every peripheral, you can do anything you can imagine with like 10 different syscalls. I think it's a very powerful design personally.