What is UNIX, Anyway?

Lieutenant writes "Technology professionals have loosely used the term "UNIX" since the first person had to explain the difference between the Berkeley and AT&T flavors, so it's not surprising to find as many UNIX standards as there are versions of the operating system. Peter Seebach wades through the wellspring of UNIX standards and sorts them out for you, concluding that the rumors of the death of UNIX are (as usual) greatly exaggerated."

Comments

Not a bad article.

[Anti-Trend]

This editorial definitely seems to be for marketing purposes, being both hosted by IBM and directly confrontational about Microsoft. Still, interesting enough article; it's always tough to be brief and to the point about such a complicated subject. I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way. That being said, the article's pretty light on the details. For those rare individuals interested in reading more than TFA, here's a little more info on UNIX and the POSIX standard.

Re:Not a bad article.

[(Score:1)]

For the history of Unix (timeline), read this one:
http://www.levenez.com/unix/

Re:Not a bad article.

[seebs]

Hosted by IBM just because it's a regular column on standardization. In all the years I've written for IBM, the only edit they've ever made on such grounds is that they changed the word "Belkin" to the name "Company X" in my article about Belkin's packet-hijacking routers. Oh, wait; I think they disliked a couple of comments I made about Verisign once. Mostly, if there's no obvious liability, they don't get involved.

Re:Not a bad article.

[ROOK*CA]

I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX.

Good point, I think the most distinguishing factor is marketing, Microsoft has been consistantly been able to map out a clear transition from API to API (as well as inserting a dash of FUD when required), even if customers and/or ISVs knew there was going to be transition pain, Microsoft was there to assure them of backward compatibility and/or easy portability (even if some of those "assurances" were a bit "hyped") . It's a bit harder for the *NIX world to communicate this to customers & ISV's since you have vendors competeing in the same space against each other and trying to differentiate their *NIX based offerings from everybody elses.

It's funny but I think a lot of customers & ISVs happily accept vendor lock-in in the case of Microsoft, but are hestitant when it comes to *NIX, even though in reality *NIX generally speaking turns out to be the more flexible (portable) platform. No accounting for taste I guess :).

Re:Not a bad article.

[drsmithy]

I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way.

Particularly since the "Win32, WinNT, WinXP" part of it are all the same thing, so the real progression is:

DOS, Win16, OS/2, Win32, .NET.

Re:Not a bad article.

[drsmithy]

Good point, [...]

Not really.

Firstly, because that list is artificially inflated ("Win32, WinNT, WinXP" are all the same thing - Win32).

Secondly, because the unix side is just as bad, if you compare apples to apples (ie: throw X and associated libs into the mix - how many widget libraries can you name ?).

Thirdly, because binary compatibility on Windows is very well maintained. It's not uncommon for those twenty year old DOS and Win16 binaries to run unmodified on Windows XP or 2003 (and probably Vista). Woe betide most with a twenty year old non-trivial unix app and no source code. Heck, with something like Linux you're lucky if binaries work between one major relase and the next, let alone 10 - 20 years worth of them.

Re:Not a bad article.

[peragrin]

Um what are you smoking?

16-bit windows and dos apps only work if they are non-trivial. I can't upgrade our work computers out of windows 95 and windows 98 because we depend on non-trivial software that doesn't run on the NT line. So MSFT is just as bad as everyone else. Try running some of the early versions of word in XP or win2k3 it doesn't work, and the modern versions can't read the older formats. been there. tried that, considered it lost.

Most linux problems aren't binaries but library and their various and multitude of locations.

Re:Not a bad article.

[sasdrtx]

I presume you mean "...apps only work if they are trivial".

I hate Microsoft as much as anyone, but if you have apps that run on Win95, but not NT-based systems, it's because they violate some fundamental rules of Window's APIs. Win95/98 were notoriously lax about enforcing those rules, which was certainly a big factor in the unreliability of Win95/98.

it's ok

[rayde]

i don't take any reports of UNIX's death as fact without a Netcraft confirmation.

Re:it's ok

[narkotix]

....no but apparently some whacko reckons aix aint made by ibm and its all part of the big plan...u know the krill files

The IBM Unix variant, AIX, is rumored to have been developed by space aliens

Re:it's ok

[NitsujTPU]

Have they said anything about Slashdot dying?

There are 11 whole posts (so far) on a story where geeks get to stroke their egos by showing their ignorance and calling everything in sight a version of Unix.

Heck, I didn't even see anybody post a *BSD is Dying troll.

Re:it's ok

[aussie_a]

Heck, I didn't even see anybody post a *BSD is Dying troll.

That's because it is already dead.

Single Unix Standard, Version 3

[Gopal.V]

As a programmer, that's what I really consider as Unix - sus v3.

I code for this API and the sources end up being source compatible. But then there are library paths and stuff, which is why even something as homogenous as Linux is forced to create LSB standard. The API standard OTOH, is crystal clear - look at the API tables in terms of availability. And yeah, my project is called Portable.net, so I've put in my time writing portable code for various platforms (even BeOS and SkyOS). Wish the threading models worked the same, that's all :)

There is just *nix ... just *nix and VMS - everything else is somewhere in between.

Re:Single Unix Standard, Version 3

[Anonymous Coward]

I code for this API and the sources end up being source compatible.

Oh boy, you haven't deployed any code in the real world, have you?

The total number of conformant implementations of SuSv3 (or even v2) is zero. None. Zip. Zilch. Nada.

Everything, including the linux/glibc, BSD, and proprietary unix-like platforms, differs from the spec in subtle and complicated ways. SuS and POSIX are paper standards, not things that you will encounter in software. They're fodder for managers and marketing; they have little or no engineering value. And the differences are important to the point where you have to modify the source of your program to support other platforms, once the program becomes sufficiently complicated. As a rule, a complex program with no platform-specific hacks is a complex program that has bugs on some platforms which have not been found/fixed yet.

This isn't likely to change in a useful manner. Most of the platforms approximate SuS/POSIX as closely as they can without breaking existing applications. Successive revisions of SuS/POSIX become more vague in order to encompass more of the things that happen in the real world. So a good way to look at these two is to consider them an inefficient and fairly inaccurate attempt at documenting the common features of a set of platforms. If this process was completed perfectly, the resulting document would be so vague and cover so many platform-specific hacks that it would be of limited value. Since the documents get updated much more slowly than the software, they will probably never be completed to a satisfactory level of accuracy.

Re:Single Unix Standard, Version 3

[Anonymous Coward]

Well, that's certainly a negative way to put it, but what if anything could they do any better? It's not like it would be particularly practical or reasonable for unix vendors at this stage of unix history to break backwards compatibility for the sake of future compatibility.

So, the unix vendors do the next best thing: they make whatever changes they can to bring their platforms to uniformity without breaking backwards compatibility, and they maintain a common standards document that documents the cross-platform compatible functionality. When they inevitably make mistakes in the documentation process, they remove specifications that they cannot implement complatibly in all unix systems.

The most important point here is the intent of the unix vendors: They are working towards compatibility wherever they can, and they are striving for accurate documentation of the compatible functionality. There's nothing to disparage in their actions, even if they make the occasional mistake -- at least they are improving all the time.

Even linux developers are known to deviate from the SUS occasionally, but they too do strive to implement the standard wherever possible. Yes, the Single Unix Specification is incomplete and flawed, but it's the best thing we've got.

Re:Single Unix Standard, Version 3

[Octorian]

Yeah, you'd have to stretch things to make those comparisons. VMS may have some syntactic similarities to DOS, but not as many as you'd think. Let's take a complete file path, for example:
UNIX: /files/stuff/foo.txt
DOS: C:\FILES\STUFF\FOO.TXT
VMS: SYS$SYSDEVICE:[FILES.STUFF]FOO.TXT;1

Though DOS and VMS both use "DIR", while UNIX uses "ls". However, both DOS and UNIX use "cd", where VMS uses "SET DEFAULT". DOS and UNIX also use "mkdir", where VMS uses "CREATE/DIRECTORY". Though UNIX uses "-foo" for command switches, where both DOS and VMS would use "/FOO", but VMS doesn't require a space between the command and the switches.

First Sale Doctrine

[David Hume]

FTFA:

A single programmer who wants a copy of the POSIX specification would have to pay US$974 for it. That gets a one-year subscription; you are not licensed to continue referring to the standard thereafter.

What about the first sale doctrine? Do they really contend that you cannot "refer" to the standard after one year? Do they do a mind wipe? Or is just that your subscription for updates lapses after one year?

Re:First Sale Doctrine

[Anonymous Coward]

They'll probably try to stop you from using it by applying the Patriot Act. I think in section 3.14.a.2.2.b it says that a terrorist is someone who uses standards documentation without renewing their license.

Re:First Sale Doctrine

[larry bagina]

You can (legally) get it for free at unix.org and opengroup.org. An individual paying a $974 annual fee for it has more money than brains.

Re:First Sale Doctrine

[TheRaven64]

More useful than the specification itself is Advanced Programming in the UNIX Environment. This is my absolute favourite reference for UNIX programming. Not only does it cover the POSIX spec (and SUS and a few others), it also tells you which bits have been implemented, and with what limits, in Solaris, FreeBSD, Linux and Mac OS X. It's slightly out of date (obviously, since it wasn't published today); for example it says that OS X 10.3 doesn't support most SysV IPC mechanisms which, while true, is not particularly useful since 10.4 does support them. It's a useful base-line though.

old paradigms

[jonastullus]

isn't unix:

- everything is a file
- every file is a stream of bytes
- do one thing and one thing well, Keep It Simple Stupid
- human readable/editable config files
- principle of least privilege
- services as daemon processes
- clear separation of kernel and userland (although this one is debatable)
- multi-user environment (despite the name)
- remote access facilities
- console/automation oriented, powerful shells
- ./configure && make && make install

?

well, that's just a few things that come to my (linux/bsd slanted) view of what (a modern) unix is...

Re:old paradigms

[grahamlee]

You've used a couple of Plan 9 and Sprite paradigms, some things which never applied to Unix[*], a load which apply to operating systems in general and an implementation artefact of GNU autoconf. I really hope that's not Unix....

[*]"least privilege" - MACs would predate setuid() if that were the case. For instance

Re:old paradigms

[grahamlee]

To take the specific point of MACs, if UNIX was about giving you the least privilege necessary to get your job done, then the concept of setuid (which gives you *all* the privileges available) would never have existed. Tools like sudo, solaris profiles, SEDarwin/SEBSD and the like have come up to try and plug this privilege leak but fundamentally, Unix has a binary privilege model. You either have none, or you have them all. More generally, I think it's hard to fundamentally sum up Unix (without using one of the technical definitions, such as "something which implements SUS"); when it comes down to it it's a C language API and a set of tools which implement that API, running a multiuser multitasking OS. I think a good description would be "an OS that one person can grok"...

Re:old paradigms

[Cow Herd (Anonymous)]

...the concept of setuid (which gives you *all* the privileges available)...

The setuid bit on an executable file gives you the privileges of the owner of the file. It is mostly used as setuid-root, but doesn't have to be.

setuid(2) is a different matter of course, because you need to have uid 0 for it to work at all.

Correlation, Causation, LSD

[Quirk]

In some cases, existing practice in a field reflects a decision a college student at Berkeley made at 3 AM.

"There were only two things to come out of Berkeley in the 60's, LSD and Unix. I doubt that is a coincidence."

great, we slashdotted IBM and Coral Cache :-P

[Hakubi_Washu]

IBM (http://www-128.ibm.com/developerworks/power/libra ry/pa-spec13/?ca=dgr-lnxw01UnixStandard):

Our apologies The IBM developerWorks Web site is currently under maintenance. Please try again later. Thank you.

Coral Cache (http://www.ibm.com.nyud.net:8090/developerworks/p ower/library/pa-spec13/?ca=dgr-lnxw01UnixStandard) :

Error: 500 Internal Server Error Server CoralWebPrx/0.1.16 (See http://coralcdn.org/) at 216.165.109.81:8090

Makes one smile :-)

Had to be said.

[deblau]

"The nice thing about standards is that there are so many to choose from." -- Andrew S. Tanenbaum, author of Minix.

The Spirit of UNIX

[murdie]

Probably the oldest standard that people still refer to is AT&T's 1985 System V Interface Definition (SVID).

I routinely use printed Seventh Edition (Bell Labs Research) UNIX manuals, even when writing C for Linux. It also helps one remain blissfully ignorant of the 'cat -v' option and similar excrescences. Also the Tenth Edition UNIX manuals. I have to remember the changes introduced by Standard C and the like, but it's convenient to have the essence of the modern-day manual in printed form. Of course, there are some people out there who delight in using Fifth, Sixth, Seventh etc Editions on PDP-11s etc - see the PDP-11 UNIX Preservation Society, http://minnie.tuhs.org/PUPS/. I wish I had a larger garage! How much would a PDP-11/40 cost me now, anyway?

Peter Salus' book "A Quarter Century of UNIX", Addison-Wesley, 1994 (corrected 1995), ISBN 0-201-547771-5 is a good informal UNIX history.

"Those who do not understand UNIX are condemned to reinvent it -- badly."
                                                  -- Henry Spencer

Mirrordot has it

[oglueck]

Mirrordot

Re:UNIX ?

[larry bagina]

XINU Is Not Unix.

(It's actually a giant space clam that wants you to give all your money to L Ron Hubbard)

Re:Unix is in everything

[zephc]

Indeed, the story of UNIX today is depicted in this documentary.

Re:Unix is in everything

[larry bagina]

VMS is absolutely nothing like Unix.

Re:Unix is in everything

[stx23]

Huh? Unix isn't remotely related to VMS.

Answer

[ceeam]

Unix is not GNU.

UNIX hater's handbook.

[mumblestheclown]

Unix hater's handbook

it's funny AND true.

/ seriously thinks UNIX like systems need to go the way of VAXen.
// well, actually not so much the systems themselves, but the assinine UNIX mentality of "harder is better" and "more documentation eliminates the need for good design.", which set back Computer Science departments and academia 15 years behind industry.
/// fortunately, one of the unintended side-effects of Linux is that the mentality, at least amongst Linux users, is slowly, ever so slowly, fading away.

Re:UNIX hater's handbook.

[MROD]

// well, actually not so much the systems themselves, but the assinine UNIX mentality of "harder is better" and "more documentation eliminates the need for good design.", which set back Computer Science departments and academia 15 years behind industry.
/// fortunately, one of the unintended side-effects of Linux is that the mentality, at least amongst Linux users, is slowly, ever so slowly, fading away.

Hmm.. yes, in /// you say that Linux programmers are going away from //. They are, they're just not doing the documentation. ;-)

Re:UNIX hater's handbook.

[AlexMax2742]

Hmm.. yes, in /// you say that Linux programmers are going away from //. They are, they're just not doing the documentation. ;-)

Which is why we have BSD.

Re:UNIX hater's handbook.

[mumblestheclown]

I think it comes down to this: when a user's input results in some unexpected output or if the user was unable or found it difficult to tell the computer what he wanted to do, the UNIXine (and this applies to GNU stuff, Linux stuff, and BSD stuff equally) response for many years was "the user made an error" or "the user's lack of knowledge is the core of the problem."

This attitude was (and to a great degree still is, though somewhat less than before) is the single most cancerous and evil mode of thinking in computer science, and yet it went widely accepted ("unchallenged" would be wrong) in Unix circles and associated hanger-on CS departments for years. The correct attitude should have been "if users are making the same mistakes and being tripped up in the same places over and over again, then clearly the fault lies with the tools themsleves."

Now, I'm sure if I go through the usual examples of this theory, I'll get back the usual result: some unenlightened idiot telling me that EMACS and/or the CLI are faster at the end of the day and therefore better, and that the problem is simply "more training." Thankfully, in 2006, I hope I don't have to explain why this mode of thinking is outdated (well, never right in the first place) nonsense, since most of you have finally woken up to these facts:

• Usability and speed are orthogonal to each other. You do NOT need to give up speed to gain more usability, and vice versa. The trick is something called GOOD DESIGN. Bad design simply trades off one for another. Good design at least imporves on one front without diminishing another.
• A long manual is a hallmark of bad design. Did you need to have a manual to start using, say, a web browser? No. Why should, say, a text editor be any different?
• i) The UNIX philosophy of "make tools small and atomic" is not necessarily bad from a deep technical standpoint, but this doesnt mean the user necesarily has to directly interact with those tools and ii) one doesn't have to be a "Windows for Dummies" esque user to benefit from well built tools. There are lots of real life examples of progress in this, from the steady emergence of (still often highly flawed, but far better than what was before) high-level languages/environments like PhP, Perl, Gnome, KDE, and so forth. There is ABSOLUTELY no reason why I can't be a UNIX guru and haven't the slightest idea what the command-line arguments to 'tar' are off the top of my head.

Bring on the 'yesbuts...' from the dinosaurs and self-annointed high priests...

Re:UNIX hater's handbook.

[mumblestheclown]

Let's get specific, shall we? The CLI itself is not the problem - it's the way it was implemented. By the early 1990s, it would have been possible - trivial even - to make a context-sensitive CLI standard that, by prompting and hinting to the user at appropriate points, would have helped the user ensure that he was typing in appropriate things. this would have in no way impacted the speed or overall usefulness of the cli, and in fact undoubtedly would have resulted in fewer operator errors and overall efficiecny improvements. You know, something to the efect that as you typed in command-line arguments to gzip, would pop up english language help right there, helping you get it right the first time.

However, this was not done in any meaningful way. In other words, while it would have been SIMPLE to add additional usability with NO loss of functionality or speed, it was not done. Why? IDIOT PHILOSOPHY.

It was not done because UNIX back then (as now) was a combination big dick and competing standards contest fought between people who basically still subscribed to the idea that they were the gatekeepers of information- the intercessory priests to the god of computing. We see an echo of this jackass attitude in one of the responses to my posts - the idea that CLI is for "experts" and KDE is for "newbies." There is, amazingly, no middle ground mentioned because the whole system was explicitly designed by a deranged "elite" so that there would be no middle ground - no hierarchy.

It's not that the CLI is itself an evil invention - it's not. It's the attitude that surrounded its many, universally poor implementations that was evil, and again, the general belief and universal attitude by those pathetically clinging to their status as "UNIX Gurus" that it was the responsibility of the user to climb UP to the system (by learning various hacks, system-specific things, and so forth) rather than changing the system ONE IOTA to, you know, actually make it easier to use. The history of UNIX-like systems, until quite recently, has largely been the opposite - make MORE incompatible, often contradictory systems so that the user is left with even more rudimentarily simple tools to accomplish ever more complex tasks.

Re:UNIX hater's handbook.

[marcosdumay]

It was done to the extent that was possible. The CLI isn't there to let the user write, it is there to automate stuff. When you want to automate stuff, you use lots of rarely used functions that your system would neglet (making the user RTFM anyway) and monitor space is extremly important. Also, you don't want some weard program messing up with the streams.

Re:UNIX hater's handbook.

[mumblestheclown]

Yes, that's right. Don't let anybody challenge your comfortble, if severely outdated notions. Meanwhile, just ignore the fact that the words "usability" and "user-centered-design" were basically nowhere to be seen in virtually any computer science department until quite recently, and even then, it's as an elective "soft" subject basically irrelevant to the "main theme." The preaviling orthodoxy of how programming is "taught", which is "code before design" and that "user-related stuff is for the visual basic programmers at the community college down across town."

You think I'm wrong? Consider something like computer vision people in CS departments who arguably should have nothing to do with this discussion. How would they be affected by this cancer? Why, for the simple reason that they were forced by convention to do their research with tools completely inappropriate to the task - low level programming languages where they had to worry about malloc() instead of actually coding computer vision stuff. NLP people who spent more time worrying about LISP parentheses than actual NLP stuff because writing an actual IDE that didnt suck and/or take a "guru" user to use was taboo and "showed weakness." Always was missing was the general idea that there should be a hierarchy of tools to make life easier or the fact that the whole point of a computer was that you can make tools to automate and/or eliminate hard and/our routine tasks. The entire mentality at MIT/CMU/Harvard (those are the places I knew best in my graduate years) was that in order to show that you had the right mettle, you had to go through the agony of learning some pointless shite in order to do something that a PC user wouldnt have to think twice about.

Re:UNIX hater's handbook.

[chthonicdaemon]

You make a few good points, but seem to have a misplaced faith in designing out problems. Let's take a look at the 'real world', which has been around a lot longer than the computer world, and see whether good design has triumphed to make the world around us work without danger and reliance on human memory or judgement.

Let's look at powertools, cars, airplanes, guns, knives or other things that modern people use. All of them have measures designed to stop people from hurting themselves and require no training to use, as their use is obvious, right? Wrong. If I design a knife that is too blunt to cut flesh, it cannot cut my steak. If I design a car that does not move fast enough to kill me if I am in an accident, the car doesn't move fast enough period. Notice how this is ok, and how we can give kids blunt plastic knives until they have learned how to use them well enough to use 'big tools'.

This pattern is even more pronounced with 'professional tools' like planers, jigs or powerful hydroulics. You need trained operators for those, because they can take of your arm or kill many people at once. The true myth of our time is that computers should be both easy to use and powerful enough to do anything you want. Design can bring you so far, but each level of ease of use you slap onto a device usually makes it that much less powerful. Observe F1 racing cars -- not an 'easy drive', but really good at what they do. Safety measures and 'easy to start' engines are too heavy, so they don't make the cut.

Getting back to the computer, there is no way to stop you from making mistakes. There are a few common mistakes, but there is no reliable way of knowing whether the user really wanted to delete all the files in that directory. I know people who have 'accidentally' deleted files in Windows, clicked on 'yes, I am sure', emptied the recycle bin and then realised they made a mistake. How was the operating system to know to stop the user? Professionals hate people looking over there shoulders, double-guessing their actions. They don't like little dogs asking them to type a file query. They like the power of a stripped down interface that allows them the freedom to do what they want they way they want. If all your needs are filled by GUI tools, there is no reason not to use them, but I prefer to get stuff done my way.

So, in the end, things get down to formalisms and language. And that's the thing about language -- it has rules. You have to learn the rules. You have to use the language often to remain fluent. What you get in return is tha ability to express yourself accurately. And thank goodness that we have a powerful language interface to the OS in things like bash.

MISQUOTE

[Anonymous Coward]

"There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson

Re:mnennnnn

[Bloke down the pub]

That command is only valid for System V type variants.

Correction

[XanC]

That's ISBN 0-201-54777-5, or 978-0-201-54777-1.

Re:mnennnnn

[ettlz]

kytf jxcjvoixcvj :: POIJP>>IPOhghghgIPO

That command is only valid for System V type variants.

Ah. I see you've been forced to use AIX as well!

Re:UNIX ?

[koinu]

I have more reliable sources than wikipedia: Linux.
I know why I'm using FreeBSD.

Re:Define it by its limitations

[moranar]

It is a mindless bashfest. Nevertheless, it is interesting. There is some truth in their madness. But they themselves admit that it's over the top and to be taken with a grain of salt. At least the book, I'm not sure about the mailing list/newsgroup.

Last time I checked, UNIX was a trademark

[layer3switch]

Yup. UNIX isn't an OS. It's a trademark and a standard. And Linux is a kernel, not an OS.

http://www.unix.org/
http://www.kernel.org/

Also Windows aren't OS. It's an opening constructed in a wall or roof that functions to admit light or air.

Lastly Apple is not a company. It's a god damn fruit. Why is that ESPECIALLY MacOS users don't seem to get that Apple Computers are PC!?!? Try to ask a MacOS user this. "Do you have a PC?" I bet, 99% of them will say "No, I don't have PC, but I have a Mac." WTF??

Re:Last time I checked, UNIX was a trademark

[Russ Nelson]

If Linux is a kernel, where is Solaris/Linux (in the same misbegotten naming scheme as GNU/Linux)? That makes no sense, of course, since the operating system *is* the kernel plus whatever runs on it. Linux is Linux, GNU is GNU, and Solaris is Solaris. Name/modifier is crap/shit. Just say no to crap/shit.

Re:Define it by its limitations

[rolfwind]

I'll disagree - it's a series of articles by people who worked with Unix (back then) and have other systems to compare it to, I consider many of the articles surpass the atyppical +5 posts here on slashdot^_^

still an amazing OS

[yagu]

I've been working with Unix/Solaris/SunOS/Linux/AIX/AUX/BSD/ATT Unix, et. al. now for over twenty years. I mostly love the environment, I'm self-taught, and never have stopped discovering new and cool (and sometimes amazing) things about how Unix works.

I've pretty much always always been able to sit down and immediately be productive in a Unix environment. Things are stored and arranged in a surprisingly consistent way (not always in the same places, but one of a few organizations (/etc vs. /usr/etc)), and for those hard to find arrangements you need only know "find".

Considering how many different Unixes there are it's actually impressive how compatible and consistent they are across the Unix universe. It's only my opinion, but I find adapting and adjusting to the Unixes far easier than the various versions of Windows.

If only that were true!

[Anonymous Coward]

Clearly you were never forced to program anything to the Win32 API.

There's a common subset of functions available on both 9x and NT flavors of Windows. (With different bugs and sometimes different supported flags, different restrictions on use, etc). Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

This situation could have been avoided if Microsoft had had the foresight to separate the Win32 API implementation from the rest of the OS so it could be upgraded independently.

Re:If only that were true!

[Quantam]

Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

I can only think of one feature that's available on Windows 9x but not NT, which isn't part of the Internet Explorer toolkit, and it's a very rarely used feature (although it's just the kind of thing I use). Almost universally, the API on NT is a superset of that available on 9x; though it is true that occasionally some small implementation details different between the two.

Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

Correct. The Windows API evolves over time, adding new and often useful features to new versions, often involving new features of the kernel. In nearly all cases these changes are backwards compatible.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

Windows 9x, Windows NT, and..? Well, I suppose you could call the ANSI/Unicode versions different, even though the differences between the implementations are usually very clear-cut (i.e. path strings are always handled in certain different ways).

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

That serves as an excellent demonstration of what I've said: the differences are usually minor enough to not be a concern, and that new features are added in a backward compatible way. Take a look: one of those differences refers to a feature that was added in XP (WS_EX_COMPOSITED), another refers to a kernel limitation of 9x, and the third refers to a feature that was added in 2000. Of those, the only "serious" one is the 9x kernel limitation, and even then it's not particularly important.

Re:If only that were true!

[Anonymous Coward]

Clearly you were never forced to program anything to the Win32 API.

Have you ever programmed on Unix/BSD/Linux systems? When writing non-trivial applications, there are substantial differences among them. Why do you think GNU autoconf was created?

Having programmed on both, I can say that Win32 is, and always has been, much more uniform across variants of the system than Unix/BSD/Linux. That doesn't mean it's better, or more consistent on any givem implementation. I generally prefer the Unix/BSD/Linux APIs, and would say they're more consistent on any given implemenration, but the differences among implementations are clearly bigger than the differences among Win32 implementations, especially if graphical APIs are added to the mix. There's also a much wider variety of different Unix/BSD/Linux systems developers have to worry about than is the case with Win32.

Re:I vote for syslog

[samkass]

You've never read a Sendmail.cf file, have you?

Linux vs UNIX

[argoff]

In all fairness, it all came from the same tradition - but when AT&T took back the copyright on their original UNIX implementation - that's when it started to seriously fragment into AIX, HPUX, APUX, DGUX, Solaris, and BSD's. Evolution slowed down drastically and left the UNIX community wide open enough for Microsoft to drive a train thru. To compensate, the UNIX community tried to force thru all these standards initiatives (renember CDE?, Motif), but they always failed to stem the tide.

Then Linux came along, and started to undo the damage that the copyright fragmenting caused to begin with because it was under the GPL, and ever since then it has been the beginning of the end for Microsoft and Linux has taken off in the server space and now it's getting ready to attack the desktop. Moral: free markets are about freedoms and not markets. When you have freedoms the markets will take care of themselves, but when you sacrifice freedoms for markets - you will eventually loose both.

60's??? WTF???

[IvyKing]

Hard to believe that UNIX came out of Berkeley in 1960's since the first tape from Bell Labs arrived in December 1973. I'm guessing the CS department wanted to have a replacement for Kronos that went away when the CDC-6400 'B' machine got shipped off in January 1973.

Re:I vote for syslog

[Anonymous Coward]

To be fair, he did say "drug induced". Sendmail.cf (Heck, M4 in its entirity) clearly is not drug induced. It is a many tentacled being which slithered forth from the darkest nether regions of hell to lay waste to the minds of humanity. On a good day.

Unix you say?

[MattskEE]

A lady struck up a conversation with me on an airplane.

• Her: "And where are you going?"
• Me: "I'm going to San Francisco to a UNIX convention."
• Her: "Eunuchs convention? I didn't know there were that many of you."

From http://rinkworks.com/stupid/cs_comeagain.shtml

So true

[mkswap-notwar]

One of the best quotes I've ever heard was from a colleague of mine,

"Unix isn't."

So What is UNIX?!

[znx]

I think that the whole discussion can be summed up, just as the article says, with:
"We reject kings, presidents and voting. We believe in rough consensus and running code." -- Dave Clark

So in answer to "What is UNIX?", UNIX is code that runs based on general agreement of the masses. This is why it will not die, even LSB is discussed in the article and rightly so, it falls into the same category. A loosely held standard that defines what the general masses of Linux distributions use.

No hard and fast standard would ever survive in the *nix world, ever system is unique to its purpose.

Nice article, IBM churn them out and every so often a good one turns up.

Re:Define it by its limitations

[rolfwind]

Check out chapter 7 titled "The X Windows Disaster: How to make a 50-Mips Workstation run like a 4.77MHz IBM PC"

I especially like the opening quote:

"If the designers of X Windows built cars, there would be no fewer
than five steering wheels hidden about the cockpit, none of which fol-
lowed the same principles--but you'd be able to shift gears with your
car stereo. Useful feature, that."--Marcus J. Ranum, Digital Equipment Corporation