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

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