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

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:Unix is in everything

[larry bagina]

VMS is absolutely nothing like Unix.

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

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

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

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.

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

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