Slashdot Mirror
What Makes A UNIX System UNIX?
ian asks: "Since there are now so many different flavors of UNIX out there (Linux, Free BSD, AIX, Solaris, AT&T UNIX, etc...) what do they all have in common that lets these all be called UNIX? Programs written for one flavor of UNIX typically cannot be ported to another without considerable effort. The features offered by the different implementations vary widely: some are more secure than others, some cluster better than others, some offer journaling file systems, some are more robust. The differences between the different kinds of UNIX seem to be as great as the differences between any particular implementation and other OSs. Could one port all the standard command line utilities to NT, clone one or two of the popular shells, set up the directory structure in the standard UNIX layout and call it Microsoft UNIX?"
What is Linux, then? Well, it's "unix-like", despite the FAQ's claim that this term is a trademark violation. Personally, I'm sceptical of the continued validity of the "UNIX" mark (once something enters common usage, it can't be a trademark), but there've been no court challenges, so it stands.
--
Others have already answered the question with reference to POSIX, but I just thought I'd thow in my two Euro as well...
Recently having ported software between Linux, FreeBSD and NT, I have developed my own idea of what a ``UNIX'' is. It's simplicity most of all. Everything is a file, and most calls that work on file descriptors work on _all_ file descriptors. You can make a select() call on a file, a pipe, and a socket. This is impossible on NT, because files are HANDLEs, sockets are SOCKETs, HANDLEs from anonymous pipes cannot be used for select() like calls (only named pipes there). Why this diversity in the API ?
Running a daemon simply requires you to start up the executable with an "&" if it doesn't support forking to background by itself. I have a routine that does this on UNIX as well as on NT. The UNIX code is perhaps 5-10 lines, and the NT code is roughly 150. On NT you must specifically talk to the service control manager, ask it to ask your program to ask it to ask the program to do all kinds of strange things. Horrible, and inflexible to the extreme.
The system calls on UNIX take a minimum necessary number of arguments, and perform some action fairly much as you would expect it to. An average system call on UNIX probably has, say, 3-4 arguments. I haven't counted the average on NT, but I'd guess it's 6-7 arguments there. This is not because NT is more advanced, but because IMO the design of Win32 is flawed.
As an example, to start up a program on UNIX, you'll write something like (dumbed down):
if(!fork())
exec("my_program", arguments, environment)
Two system calls that perform a very clear and simple task each, taking 0 and 3 arguments.
The similar code on NT is something along the lines of a call to CreateProcess() which takes 10 (ten!) arguments. These arguments are: program name, command line and environment as on UNIX. Besides, you'll have to pass arguments such as current directory, process security attributes, thread security attributes, filehandle inheritance flag, creation flags, etc. etc. My favorite is that you have to pass an argument specifying the Window Size (!!) of your new process... I nearly pissed my pants when I saw that.
UNIX system calls are fairly consistent. Usually they will return either a 0 pointer, or the integer -1, if the call fails (depending on whether the call returns a pointer or an integer). On NT the calls return either INVALID_PROCESS_HANDLE, INVALID_FILE_HANDLE, INVALID_SOCKET, FALSE, 0, -1, or whatever the failure-return-code-of-the-day was when some call was last rewritten. Error codes can be retrieved from errno on UNIX, while on NT they come from GetLastError() usually (with some exceptions I've happily forgotten about), unless of course it was a socket call that failed, in which case the errorcode can be retrieved from WSAGetLastError(). Sigh.
The point I'm trying to make here is, that to me UNIX stands for a _fairly_ consistent and well designed API. Win32 is neither well designed nor consistent, and porting command line utilities to NT is not going to make it UNIX, not by a long shot.
The basic cause of the backspace problem is a different ASCII code for the key in DEC terminals (where it's 0x7F) and others such as Sun systems (where it's 0x08). Unix is configurable (using the stty command) to deal with either, so that it didn't really matter too much.
A modern Unix-like[1] system is a blend of many different threads of development, with both Sun and DEC well represented. So, the Linux console follows the DEC convention, while the xterm's in most distributions follow Sun (Debian is the major exception here).
So, in a system with the backspace problem, you have many factors coming together:
And, no from-the-ground-up reconsideration of the system, during which the backspace problem would certainly be fixed.
If that doesn't define Unix, I'm not sure what does.
[1] Yes, I know it's an "abuse of the trademark." The Open Group can stuff it.
LILO boot: linux init=/usr/bin/emacs
You know it's Unix when the backspace key often performs an action other than deleting the character to the left of the cursor.
When (actually if) this problem is fixed, the system will have changed so much from Unix that it probably wouldn't be recognizable to Thompson and Kernighan.
LILO boot: linux init=/usr/bin/emacs
A unix system is like an orgasm. When you have one, you'll know it.
--
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
I think the most important thing to realize is that no single thing defines what makes Unix be Unix instead of Just Another Operating System. Sure, there is POSIX, but POSIX doesn't cover everything. Sure, there are the "standard" Unix shell tools, but those can be ported. You can't nail Unix down in any easy definition. Yet, Unix inevitably feels like The Right Thing to those who know it. If you like cliches, Unix reminds me of the old line "I don't know art, but I know what I like."
/, and cannot function without it. It is more then not being able to do anything useful without the programs in the root; it is the fact that the Unix filesystem is a large part of the Unix API.
/bin, configuration data in /etc, devices in /dev, temporary files in /tmp, "user files" in /usr. None of these are mandated by the kernel or the utilities, but they are definitely old friends to a Unix hacker like me.
That being said, I'd like to touch upon a few things that make Unix what it is:
The design of Unix is driven by synthesis. You don't create a specific tool to solve a particular problem; you break it down into smaller, general problems and write general tools to solve them. You then combine those tools to solve the original problem -- but you can continue using them afterwards.
This leads us to The Unix Philosophy. Anything you call "Unix" or "Unix-like" will adhere to it. However, the Unix philosophy is a set of design goals, not a system definition. Something can follow those goals without being Unix. So that doesn't cover everything.
Let's start with the filesystem. As others have said, a key element of Unix is the single filesystem. Unix must have a root filesystem mounted at
Additional filesystems are spliced into this single presentation, not mounted as separate trees. System hardware is abstracted and presented using file system entries. These are things that cannot be done if your OS doesn't support them. Then you have the organization of the files in the Unix filesystem. Programs in
Unix processes also behave in a certain way. Process spawn overhead is low and context switching is fast. Signals and exit codes are used for IPC. fork() and exec() are separate system calls.
Unix treats text as data and data as text. Configuration files are generally human-readable. You can "cat" a binary file without the OS doing end-of-line manipulations. Any particular meaning of a character (^D for EOF, e.g.) comes from the terminal driver, not the I/O mechanism.
Lastly, Unix was implemented in C, and C was designed to implement Unix. Contrast this with other OSes, where the language you're programming in and the system library are generally completely separate things. This synthesis (to borrow from the Mazda ad campaign) "just feels right".
While I'm on the subject, I'd like to address two things that Unix explicitly isn't:
Unix is not a trademark. I'm sure The Open Group doesn't agree with me, but Unix was around before they were, and will continue to be around long after they are gone. They control who can legally put "UNIX" on their product, but that is a matter of layers and money, of which Unix cares about neither.
Unix is not a particular source implementation. There are very Unix-ish things which have not one line of AT&T or BSD code in them, and there are things totally not Unix which contain BSD code. MS-Windows is one of them.
I forget who said it, but if you're looking for one line answers, then this fits best:
"Unix isn't so much an operating system as it is a painstakingly compiled oral history of the hacker culture."
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
- POSIX compliant system API
- Availability of traditional UNIX shell tools
- Ability to run without a windowing system
- Modular design
The question is like asking "What's a car?" BMW, Mercedes, Honda, GM and lots of others fit the mold without there being a 'definitive' car. I think the same applies to UNIX: there's lots of variants, based on the same basic (and time-tested) design. I've done some software porting across different UNIX systems and in my opinion, the differences between these systems were blown out of proportion by the marketing machine from Redmond (and others). There are differnces, but they're manageableAlso, while this is not as true anymore as it was a few years ago, I would say that an important part of the UNIX philosophy is the fact that most configuration parameters (and other useful stuff) are stored in plain text files (yes, Solaris and AIX don't do this anymore, but the basic idea is still there). You could port all the shell utilities to NT only to find out that they're basically useless as everything is stored in some binary file that you can't really process with your trusted text tools. ASCII is portable and accessible; a fact that UNIX really drives (or at least should drive) home ...
It's a well-kept secret that the NT Executive has a single-rooted hierarchy, containing device nodes, named pipes, and filesystem roots. It even supports mount points, sort of, via a concept called reparse points.
Of course none of this does us any good, because the Win32 subsystem does its best to hide whatever elegance lives in the NT kernel. You can get glimpses of it... for example, try opening the file \\.\PhysicalDrive0 for reading (don't write to it, that's your raw disk sectors!).
You get the feeling that NT could have been something better if they didn't have to make it compatible with Win9x.
Oh, and BTW, NTFS on Win2k does symlinks too.