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

it's ok

[rayde]

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

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.

Re:Not a bad article.

[(Score:1)]

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

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.

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

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

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

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

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

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)

Answer

[ceeam]

Unix is not GNU.

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.

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

[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!

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:I vote for syslog

[samkass]

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

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