I have always had the problem of people asking the difference between UNIX and Windows, and wrote this website to help explain. Please read and let me know how I can make it better. I will put your name or screen-name in Authors/Editors part at the bottom. If anyone is willing to host this on their domain that does not have ads, I would be grateful and will send you the raw html code.

http://www.geocities.com/whitehat4u/explain.htm

OK-I have made a few changes, offer still stands, I need some advice on what I should change.

I point people here.

Ya, thats not bad. Out of curiosity, did you read my page? If so, was I right?

Comparing all *nix operating systems to Windows is not a small task.
For me the building analogy does not make any real differences clearer.

I simply was trying to explain the 'distance' of each operating system from hardware itself. Also, I was writing it very simply, and I don't take you for a newbie to Linux, it may be that you over-analyzed it.

That is always possible.
When I read a thread by someone who seems to really be interested in using Linux but wants to find Windows answers I point them to the link I posted above. I feel it introduces and discusses the topic very well.
My criticism is not that you fail to teach me anything new but that I do not see where posting this as a response to a question would make any point clearer.
As you say, this may be over-analyzing.

Lol-you are definitely over-analyzing it. I am intending to answer newbie questions that tend to be: What is Linux/Unix/or BSD, and what really is an operating system? I was simply showing in a simple way what the difference is with an analogy. I am tired of having to answer the question-what is Linux? What is an operating system?

Okay.
Good Luck

I don't know that it actually explains much at all. It does introduce new amounts of confusing and misinformation. I am not trying to sound harsh here, so take it with a grain of salt and know that I say this kindly.

With regards to level, binary and hexadecimal are equivalent. The only difference is human ease at using. A CPU doesn't "understand" binary 1010 anymore than it understands 0xA. They are exactly the same thing to the CPU, a series of high and low bits which hold a representation internally. In the sense that there is no translation going on... these are at the same level to a computer.

The next step above that would be bare assembly, where each and every instruction literally translates into a specific bit pattern which is understood by the CPU.

Then you have traditional assemblers which use macros and other tricks (like labels) to make the job a little less tedious.

And so on... up the programming tree. But all of that has nothing to do with operating systems. In fact, Windows 9x was much "lower" in this respect than Unix ever was... in that it allowed you to directly control the hardware from your programs. Anyone who has ever written a (Windows/DOS) program which made calls to int16/10/etc... all were taking advantage of the low level access of Windows... which was functionally much closer to the hardware than Unix was (especially post-v6).

Traditionally, Windows expected a single-user so it allowed you to directly modify hardware. Unix, which was traditionally multi-user, required that you make a request to the operating system itself, which then would directly work with the hardware. It provided an abstraction layer -- Windows did this as well but there were many reasons to ignore the Windows method and do it yourself.

So... I am confused as to what exactly you wanted to represent with your floors analogy... I don't even understand it well enough to suggest how to fix it.

The second problem that I see is that I don't agree with how you classified the "Unix and Unix-like" operating systems. Unix itself is (or can be) very graphical. Anyone who has used Irix or Solaris has experienced a very graphically centered Unix OS. The GUI part of *nix is inconsequential and almost all of them supported X and the various window managers that run under them. Solaris will run KDE if you want it instead of CDE or the new Java Desktop. And full 3d support in Unix is normally associated with Irix which had a simply astounding graphical interface -- I am seeing things it was doing years ago in consumer grade OSes today.

The graphical way of sorting Unix-like Operating systems isn't reliable. Especially with Linux as the BSDs and Solaris will run all the Window Managers found on Linux (and more). I often pine for a proper CDE on *nix -- and, before anyone says it, XFCE isn't nearly good enough. At best, I would say that you'd need to rank all the Unix-like OSes on the same level, with some Unix systems there as well, and you can put Windows just barely above them (although I would put it below them since the WM in Windows is subpar IMO). It's obvious that it's just too convoluted and subjective to use this as a standard.

You can try and classify them by History... but that leaves Windows and Linux sortof just hanging out there... and doesn't really show what you want to show.

If you're trying to classify them by traditional standards of "ease of use (including setup) for newbies) -- which will keep your original ordering -- you can say that traditional Unix has been harder to setup than the BSDs. And Linux is easier than the BSDs to setup. And Windows is easiest of all -- for the inexperienced.

Now, I would say that the "traditional" view on the difficulty isn't really valid. It certainly has issues as the categories are too large and the overlap is insane... also it depends on what the end-user needs the computer for.

I have to say, I don't see any real help understanding this. I don't think "levels" is an easy way to classify them. Even if you find a consistent manner which to assign values, the results are all opinion and open to debate.

----------

Edit:

Let me add that Unix is one of the furthest OSes from the hardware that one can get. The ideal Unix is completely abstracted from the hardware. /dev/{whatever} hides all the details about the hardware itself and just presents the program with a file to manipulate. [The vast majority of] Programs have no comprehension of how the filesystem is arranged on the disk... they don't even know what an inode is... or a vnode... or any of the other internal structures which abstract the details out. It should be impossible for a program to even know if a file is local or coming from across the net through an NFS mount... all it sees is the file... it has no idea about what is going on underneath it.

This is especially seen in versions of Unix which work on different platforms. When a program calls open()... it has no idea what sort of hardware it is talking to or how it is. That open() call may compile to a sparc chip, which is talking over the hme1 interface to a file on an alpha server running a different version of Unix entirely. Or it may be on a 386 computer talking to a local IDE drive. The program itself has no comprehension of the architecture or the hardware. It sees a file. That is all. The kernel handles all the requests relating to that file and deals with all the details.

Hmm, I think I will rewrite it, and try and make it more accurate and understandable, as it is obviously controversial.

I hope you don't think I am being a jerk or overly picky. If I didn't want to help, I wouldn't have posted anything -- or at least would have posted a lot less and just moved on.

Ya, I understand. I just need to make something obvious enough for a newbie to understand it. I was mad when I wrote it... ;-)

Hey, can you look at this?(My very first post/problem)

http://www.linuxquestions.org/questi...d.php?t=527170

OK, I have updated the webpage. Try it now.

Anybody like this better?