What Makes A UNIX System UNIX? 417
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?"
NT not Unix, though A/UX was much closer. (Score:2)
A/UX, on the other hand, was a true Unix OS at the core with the "Macintosh" shell running on top of it. I really liked A/UX. Whatever happened to it? When did Apple officially abandon it?
It's "Unix" if it has the 'x' sound it it's name! (Score:2)
Unix.
Linux.
Ultrix.
Irix.
Miltics. (variant spelling, but has the same 'x' sound)
Xenix.
even A/UX.
Because the following have no 'x' sound, they are mere Unix wannabees or early protozoan forms thereof, and not True Unix Clones at all.
Windows NT.
SunOS/Solaris.
BSD/NetBSD/FreeBSD.
NT branded Unix (Score:2)
NT qualifies under UNIX98 branding as a Unix system when running the compatibility overlay previously known as Interix/OpenNT. Covered in this ZDNet article [zdnet.com]. MVS has also qualified for Unix branding, IIRC.
Not that I think of NT as Unix.
What part of "Gestalt" don't you understand?
Scope out Kuro5hin [kuro5hin.org]
Re:Nope. (Score:2)
No. Linux was written from scratch. The Minix FS was the first filesystem supported, which accounts for the mistaken impression in your post.
-Doug
Re:What a clueless question! (Score:2)
I would add "written ... with portability in mind". It's easy to be gratuitously nonportable, especially if all you know is one flavor.
-Doug
The Single UNIX Specification! (Score:2)
A draft of this is available online and makes a handy reference [unix-systems.org].
The Single UNIX Specification covers not only the library and system call interfaces, but also the shell commands and utilities, including the command language formerly known as Bourne.
Of course, what we actually understand as UNIX is deeper; one cannot understand what UNIX is outside of the surrounding computing culture.
Re: QNX (Score:2)
Yup. I've got one. Hardware is an 80186-based system (more embedded computer) with some kind of weird-ass token ring network. I contacted QNX for information about these systems, as I have done with Unisys but neither was able to help. Is there anyone here with hardware information on those old Unisys ICON computers? I have a few I'd like to play with...
Re: QNX (Score:2)
These I believe were ICON 2's (80186 computer, Arcnet-type network, diskless. Color screens with blue background.
The teachers watched us *very* closely with those things. I remember getting in shit for trying to get to a prompt...
Re:POSIX, not UNIX. (Score:2)
Re:NT not Unix, though A/UX was much closer. (Score:2)
Clarification: Unaccelerated 16-color (4-bit), 640x480. In other words, base VGA.
What makes a Unix? POSIX. (Score:2)
As for making WIndows NT into a Unix, it's already been done; for a while it was being sold as Open NT. Essentially, Windows NT has the capabilityto have different subsystems; the 16 bit Windows 3.1 compatability stuff is one, the Win32 level another. By adding a complete POISX subsystem, Windows NT can be considered Unix. Bill Gates was once quoted "In some ways, NT is a Unix". For more on the history of Unix, I recommend the book A Quarter Century of Unix by Peter Salus, the USENIX bookworm. It has an excellent explanation of the geneology of Unix and Unix-alike systems.
Re:My highly subjective opinion (Score:2)
1.The file system interface. By this, I mean inodes, ugo/rwx permissions, and a single hierarchy rooted at "/".
A number of non-UNIX OSes have borrowed this paradigm (INMOS's Helios and Be's BeOS are two examples; many real-time OSes also borrow from UNIX here).
2.There is one user (root) that has full access to the machine; all other users are limited to a small "sandbox"
Some secure unices eliminate the omnipotent root user and compartmentalise privileges further.
Other indicators of an operating system's UNIXness would be:
Re:GNU autoconf/automake (Score:2)
Re:Microsoft UNIX NT (Score:2)
Why POSIX isn't enough to be called "UNIX" (Score:2)
Via its Interix purchase, Microsoft now has the technology to make Windows NT/2000 totally POSIX.1 and POSIX.2 compliant, complete with X Windows! A free alternative to that is Cygnus's Cygwin environment, which is a complete port of the GNU tools (POSIX.2), along with an API layer that translates POSIX.1 calls to Win32.
But just use a Windows NT box running Interix or Cygwin. It's obviously not Unix.
To be Unix, the following have to be true:
In all these "POSIX-but-not-Unix" systems, the Unix functionality is secondary to the "native" functionality. Most of the time, there's another way to do something, a way that makes more sense on that system than the Unix way.
--
UNIX specification set by Open Group (Score:2)
There are UNIX 95 and 98 specifications along with delineations between server and workstation class machines.
You can view version 2 of the specs on line at this URL:
http://www.opengroup.org/online-pubs?DOC=007908
API tables can be viewed here:
http://www.UNIX-systems.org/apis.html
They are useful for distinguishing between what is BSD, SVR4, POSIX, and modern UNIX.
If you read some of the specification docs, it states what C-language system calls must be implemented and draws the boundaries between what features must exist and what features are up to the discretion of the implementor.
Note that it is possible for systems that are not traditional UNIX to get the certification. I think DEC did this with OpenVMS. The Interix product also has this certification.
There is an effort to bring UNIX and POSIX closer together. Information can be found here:
http://www.opengroup.org/austin/
Re:Files, baby! (Score:2)
...and you probably won't see them on a BSD box, either:
The /dev entries for devices are a DLPIism; they weren't in SunOS prior to 5.0, and there are a number of UNIXes that lack them.
Re:Serious followup (Score:2)
The original character used to "[delete] the character to the left of the cursor" in UNIX was...
...'#'.
Yup, '#'. It was what Multics used, just as Multics used '@' to erase the line, and UNIX from Bell Labs followed in its footsteps, the fact that Multics largely ran the terminals in mode where echoing of characters was done by the terminal (in fact, as I remember, you didn't have a choice about it on at least the IBM 2741 Selectric-typewriter-based terminal; the special option to allow the host to turn off echoing worked, as I remember, by the terminal mechanically blocking the Selectric typeball from hitting the ribbon and the paper) but UNIX ran the terminals in a mode where echoing was done by the host nonwithstanding.
DEL (0x7F) was typically the interrupt character, to send a SIGINT to the currently running program; on CRTs, people may have chosen BACKSPACE (0x08) as an erase character - at least it would be echoed as a backspace, even if it didn't actually remove the character from the display, or work well if you were erasing a TAB character.
Some folks made the tty driver more like those in DEC's operating systems, where DEL erased the most recently typed character and either erased it from the screen on a CRT or echoed the erased characters inside backslashes on printing terminals, control-U erased the line (possibly erasing the entire line from the screen), and control-C was the interrupt character; BSD did so, and that tended to make DEL the erase character (even on Suns; as I remember, on Sun keyboards until the Type 4 keyboard, the big key on the top row sent DEL, not BACKSPACE; the Type 4 went more PC-like in what I remember being in part an attempt to make the PC users they hoped would pick up on the Sun386i happier).
So the basic cause of the backspace problem, in the sense of BACKSPACE (0x08) not being the standard erase character, was that the AT&T folks emulated Multics and the Berkeley folks emulated DEC. The problem of the big key on the top row of the main keyboard not erasing the previous character is a result of it sending (or, on workstations/PCs, not being interpreted as) DEL on some terminals. (Digital tended to make it send DEL on their terminals because that's what their OSes used as the erase character; I forget what other older terminals did, but some later terminals may have made it send BACKSPACE either because, well, that's where the backspace key goes on a typewriter or because that's where it goes on a PC. I guess the PC has it as a BACKSPACE key because the original IBM Personal Computer was made by a company that also made typewriters :-))
Re:*nix and binary emulation (Score:2)
If you're speaking in the strict legal sense, then, once upon a time, AT&T did, as I remember, impose such a restriction on the use of the trademark - except that it was much stricter, i.e. you had to have made minimal changes to the source code, just enough to make it run on your hardware. (That's why "Sun UNIX 4.2BSD Release 3.x" became "SunOS 4.x" - Sun, and Berkeley, had made rather a lot of changes to the code base that had nothing to do with making it run on Suns, and we figured that'd keep AT&T from yelling at us.)
However, the UNIX trademark is now owned by The Open Group, and anything that passes one of the UNIX test suites (e.g., the current one, the UNIX 98 test suite) can, in theory, be called "UNIX" even if it lacks any AT&T code whatsoever.
If, however, you're thinking of the general "look and feel", I don't care whether the code is AT&T-derived or not - if it looks like a UNIX system when I use it or develop code for it, I'll call it UNIX (even if that upsets either The Open Group or the "Linux is not UNIX" crowd).
Depends on the type of "binary compatibility". Many UNIXes (or "UNIX-flavored OSes", for the benefit of those who piss and moan about thinking of Linux as a UNIX) include the ability to run binaries for other UNIXes running on the same instruction set architecture, and this capability can come in handy if some program is available only in binary form and you want to run it on an OS other than one for which its binaries are available.
Re:Nope. (Score:2)
OK, you're wrong.
UNIX is a trademark of The Open Group; it used to be a trademark of AT&T.
At least at one point when it was a trademark of AT&T, to be able to use that trademark for your software it had to be based on System V (which contained not a line of code descended from PDP-7 UNIX, given that said PDP-7 UNIX code was almost all if not all PDP-7 assembler code; it may have been philosophically influenced by it, but, well, so was Linux and the userland code put atop it...), with the only changes being those necessary to port to the hardware on which it ran.
However, now, you can get a license for the UNIX trademark if you pass one of The Open Group's test suites, even if there's not a line of System V-derived code in your OS.
And I consider Linux to be a flavor of UNIX, in the sense that, when I log into a Linux system, and when I develop code to run on (among other platforms) a Linux system, it feels as much like using or developing code for some AT&T-derived UNIX as using or developing code for one of those AT&T-derived UNIXes feels like using or developing code for another of those AT&T-derived UNIXes.
I tend to consider the sine qua non for being "real UNIX" to be the administrative interfaces, in that UNIX-compatible or UNIX-like environments atop other systems don't change the way you administer those systems, so it's still significantly different from UNIX, but administering a Linux system feels much like administering an AT&T-derived UNIX system (heck, on most Linux distributions, the rc files are more like System V than are the rc files on the ultimately AT&T-derived BSDs...).
Re:Portability? POSIX! (Score:2)
There is a set of standards called POSIX, and the core POSIX API standard, IEEE 1003.1-1990, sockets are not specified.
There's another 1003.x standard group that is, I think, working on standardizing a low-level network programming API, but I don't think it's a final standard yet (and it may get swallowed up by the Austin Group work mentioned in the next paragraph).
The Austin Common Standards Revision Group [opengroup.org]
and it appears that standard will contain a lot of stuff not in 1003.1, including networking interfaces such as sockets.
The point here is that there's more to UNIX than just POSIX; there are API not standardized by POSIX but that are (more or less) common to many UNIX-flavored OSes and that are important for many applications.
Re:Give Credit where its deserved. Was Re:Xenix (Score:2)
...but those things are the same on all "UNIXes"? I'd be extremely skeptical of such a claim; I suspect that you'll find a fair number of kernel differences between, say, AIX 4.x, SunOS 5.x, and Digital/Tru64 UNIX, for example.
...which is why I call it a UNIX, even if it's not AT&T-derived (especially given that a fair bit of AT&T code has, I suspect, been rewritten or replaced in the kernel and userland of even AT&T-derived UNIXes).
Re:Xenix (Score:2)
Nope. "One", i.e. Microsoft, didn't "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", they took V7 UNIX and ported it to various platforms and added the usual set of enhancements ("usual" in the sense that pretty much everybody with a version of UNIX they sold did so; that flavor of "embrace and extend" was hardly unique to Microsoft).
(...just in case anybody in the audience doesn't think Microsoft ever sold a Real AT&T-Derived UNIX. They most definitely did....)
Re:NT branded Unix (Score:2)
They don't seem to be listed on The Open Group's page listing UNIX 95-branded products [opengroup.org], but I don't know if that page lists everybody who got the brand (that being the brand the ZDNet article says they went for).
It is, however, from the stuff on Interix on the Interix Web site [interix.com], a lot more UNIX-compatible than is the native POSIX subsystem on NT.
Well, OS/390 did [opengroup.org], but "OS/390" is just the latest in the series of names assigned to various descendants of OS/360, MVS being an earlier such name for the descendant that's now OS/390.
Re:The smarter... (Score:2)
I've heard the claim that it's VMS-derived, but I've not heard any evidence sufficient to make me believe that claim. At least some stuff is VMS-like internally (the I/O subsystem, according to the Inside Windows NT books, resembles the I/O subsystem described in VMS internals books), but that could be nothing more than the result of Dave Cutler being, I think, in charge of the development of both.
"3.x" was the first release of NT - 3.1, to be specific. I guess Microsoft wanted to give it version numbers that resembled the version numbers for Windows OT, so they started with 3.1 rather than 1.0.
Given that VMS wasn't "a true UNIX" (as in "had an API and a command-line interface that wasn't particularly like that of any UNIX"), I'd say it wouldn't.
If
then I'd consider it a UNIX.
Re:What makes a Unix? POSIX. (Score:2)
Umm, as far as I know, HP-UX, at least on the 68K and PA-RISC machines, is ultimately derived from AT&T UNIX (there was one other box they made with a UNIX built atop some special kernel they did, on a processor that was neither a commodity processor nor a PA-RISC processor - but even there I think most of the userland stuff, at least, was probably derived from AT&T UNIX), as is Solaris (and Solaris is, as far as I know, far from just being vanilla SVR4).
And now it's being sold as Interix [interix.com].
Re:W2K *IS* UNIX Branded (Score:2)
I doubt you can, even with Interix installed...
...but you can't do that on the BSDs, either, unless you've installed a System V-style init on them (which may require you to write one, or port one from a Linux system, say), unless you include changes between single-user and multi-user mode, which is all you get with the traditional init, to be changes to the runlevel (which I don't, given that the notion of multiple run levels first showed up, at least in an AT&T UNIX release that AT&T sold publicly, in System III, not in the original Research UNIX).
I suspect not, even with Interix...
...but I suspect you can't do that on a headless Linux/BSD/Solaris/SCO/... system with a dumb terminal on a serial port as a console, either. (There may be equivalents for dumb terminals, though.)
I agree that NT+Interix probably not UNIXish enough for me to think of it as Real UNIX (although for many purposes it may be Good Enough), but those particular criteria are a bit too restrictive, in that they rule out systems that I suspect most would think of as Real UNIX. (And I think of Linux distributions as being Real UNIXes even though their code largely can't "traced back to AT&T or BSD UNIX".)
Re:UNIX, source & perception (Score:2)
That actually dates back to V7 UNIX; it's not an HP-UXism. As I remember, the rationale was that if you did that, and the machine crashed before the program running that image exited, you'd have an "orphaned" file...
...but I consider that a lame rationale, as
Re:Its Unix iff... (Score:2)
Yeah, calling them ".so"s instead makes a big difference. :-)
Presumably by "no DLLs" you mean something other than "no dynamically-linked libraries", given that most modern UNIX systems these days do have dynamically-linked libraries.
Given that, to which particular feature or features of Microsoft's implementation of dynamically-linked libraries are you referring?
Re:Don Knotts Page (Score:2)
Try searching for "OpenDK" in Slashdot comments - and then go to the second page on the "DNA Testing to solve history's mysteries?" page, or whatever it's called.
UNIX98 (Score:2)
http://www.opengroup.org/prods/xxm0.htm
Interestingly, Linux is not a fully compliant UNIX system as you might think.
Re:windowing system (Score:2)
--
Re:Blame Win32 (Score:2)
Yes, but unlike Unix where Everything Is A File, in NT only some things are files. There are also various mysterious base system objects which you can apply an ACL to, but does not exist on the filesystem.
--
Re:windowing system (Score:2)
However, inclusion of CDE and Motif are required as part of the "Single UNIX(tm) Specification", so you could consider the windowing systems as part of UNIX(tm). This is one main reason that free Unix clones will never be certified -- CDE is not free software, and nobody has any interest in cloning it.
--
The "file" metaphor? (Score:2)
/etc/passwd is a file.
/dev/null is a file.
a socket is a file.
All things are interacted with in the same manner, and this consistent abstraction, along with a common API and tool set, are what makes it easier to go from one flavor to another.
I don't think any OS, except maybe MULTICS (don't know it) which is UNIXes daddy, did this before.
The smarter... (Score:2)
Stability? (Score:2)
Also, think of the user experience. For the most part, end users of a unix system experience the same behaviour. cd is cd is cd, cdup is cdup is cdup. cp, mv, vi/pico/emacs are all there, etc. etc. It's only on the back end that the Unices vary so widely. I've moved my old website from HPUX to Sun to Linux to OpenBSD, with others in between and the only major changes were due to differing security/CGI settings and the path to perl...
Opera compliance, duh. (Score:2)
Non-eunuchs develop normally, but loose the ability to be Opera compliant (except at a very bass level). Furthermore, non-eunuchs gain the ability to really dick people over, as witnessed Feb. 17th.
Re:Cygwin (Score:2)
--The knowledge that you are an idiot, is what distinguishes you from one.
Cygwin (Score:2)
Anyway, I would say that a requerement for a UNIX is the two basic UNIX philosophies; pipes and the file tree. The previous being that everything is done in small programs linked to each other to do complicated tasks, and the latter being that all communication with the outer world is done through the filesystem through device files.
But if the latter is a criterion, most unices aren't unices - the network interfaces are rarely real device files.
Another aspect of UNIX may be that everything is done in human readable format - you rather patch and recompile a source file than you binary patch or relinks.
--The knowledge that you are an idiot, is what distinguishes you from one.
Amiga ixemul.library (Score:2)
Pretty much all of the GNU tools, and X windows, that are commonly found in a base linux install were then compiled into a distro called GeekGadgets to run on top of the ixemul.library on top of AmigaOS...
A similar approach could, I suppose, be used on top of virtually anything.
It used to live at www.ninemoons.com/GG/ [ninemoons.com]
Re:unix tools for win32 (Score:2)
And (Windows NT && cygwin && bash && grep) != Unix
Re:unix tools for win32 (Score:2)
sh and csh *are* unix tools because one can count on them being installed by default on every unix. Ditto for vi.
Only those (Score:2)
As to something being written for one unix being 'difficult' to port.. this is not really true. Most things these days port rather easily.
Re:Actually I give a rip. (Score:2)
NT can surprise you. I once wrote a long, complicated shell script that would install and upgrade objects in databases. All our clients would use it. It used all kind of shell tricks, and tools like sed, awk and grep. It was developed on Solaris. Then I had to port it to HP. Which required some changed. (I remember that grep under Solaris had options not supported by HP's grep; but they both claimed to be POSIX compliant). That program was later ported to NT. It required one change: a different directory than /tmp was used as scratch place.
There can be a zillion reasons to hate NT (I would never use it myself). But lack of standard Unix tools isn't an appropriate reason - they have been ported.
-- Abigail
Re:Portability? POSIX! (Score:2)
Except of course that not everything in Unix is a file. That's Plan 9. If everything was a file, you would not have open and pipe and socket with friends. If everything is a file, you'd have one API. Unix doesn't.
-- Abigail
Re:Stability? (Score:2)
$ which cdup
$ which emacs
$ which pico
$ uname
Linux
$
Does that make Linux a Windows variant?
-- Abigail
Re:Actually I give a rip. (Score:2)
Wrong.
Had you used the GNU tools on Solaris and HP, you'd be better off for compatibility.
That was not an option. And even if it was, I'd prefered to use the out-of-the-box solution than to be forced to keep sources around for several years in the off chance someone might demand them.
-- Abigail
Re:My highly subjective opinion (Score:2)
So, if Microsoft would start porting their software to Linux, does that mean Linux is no longer a Unix?
-- Abigail
doh... (Score:2)
operating systems than Unix.
And a system does not have to be stable to
be called Unix.
It is just a common trait for most Unixes, that
they are very stable.
Userexperience isn't everything either.
It could be argued that MacOs X is a variant
of Unix, because of the kernel, and Posix-compatibility.
But the user experience would probably be very
different.
What makes Unix Unix, is probably conforming
to standards (Posix), and the basic architecture.
The philosophy ("everything is a file").
You could emulate the Unixinterface trough a sort
of virtual machine in Windows NT.
Windows NT would then feel like Unix, but it
really isn't. The virtualOS probably IS
Re:Files, baby! (Score:2)
If everything is accessed as a file, it's probably a Unix. No special hidden "registries", no extended invisible attributes, just files.
Ethernet on
Entire physical or logical disk drives accessible under one filename (/dev/hda,
Serial ports as a file, printers as a file, etc...
That's UNIX. Accept no substitute.
If that's the case, then Linux is not an unix....the networking interfaces have - traditionally - not shown in
Just not to confuse anything....
Re:MS Unix (Score:2)
Wrong. If I recall my history correctly, when faced with a new set of processors and a new type of system (in terms of memory hierarchies, I/O capabilities, etc.) MS tried two different approaches in parallel. One was to port NT, and one was to write a new OS originally called Pegasus. The latter approach won out.
I got this information from the intro of a book called Essential Windows CE Application Programming, by Robert Burdick. It may therefore not be totally authoritative, but it seems a little more believable than an unsubstantiated claim on Slashdot.
Re: QNX (Score:2)
-- iCEBaLM
Re: QNX (Score:2)
The icons were the definitive network computer.. We had farms of them in our schools around here (belleville quinte area). There were 3 types, the Icon 1 was really old looking and clunky, the Icon 2 was newer looking but seemed to have the same hardware, and the Icon 3 was nothing but a (3|4)86 with a "Unisys Icon" sticker on it.
The Icon 3, running QNX, would serve the OS and apps to the other Icon 1 and 2's, which were diskless, on the network, but I remember it being a 10base2 network, not token ring...
I had great fun with these, I eventually found out how to get to shells, and I'd go into other students directories and check out their homework
Its interesting to note back then however that these early versions of QNX did NOT have a flat file system, they were segmented into logical drives, [1]1:/path if I remember correctly.
-- iCEBaLM
Re:The real definition (Score:2)
A Windows UI blitz-quiz:
- When do you press Ctrl-/ and when Ctrl-A to select all items in a list?
- How do you explain that to a *user*?
- What will happen to a file when you drag it from one folder to another?
- How do you explain that to a *user*?
...
Re:windowing system (Score:2)
My job is being part of a team who manages over 400 sun servers. Do we have monitors hooked up to each of them though? No. We use a serial terminal server to get consoles on them. Sure the use of a GUI is nice from time to time, but to do maintenance on a system it is definitely not necessary, and I think that is the main reason the person who listed out possible criteria for unices stated that a windowing environment was not required.
siri
It's the architecture (Score:2)
--
Patrick Doyle
Two correcting facts (Score:2)
2) Linux is not Unix. It is a free Unix-type operating system.
Chris Hagar
Re:POSIX, not UNIX. (Score:2)
--GnrcMan--
Re:Actually.. (Score:2)
Sometimes there are reasons to give up a bit of stability and speed.
--
linuxisgood:~$ man woman
Re:If it looks like a duck and quaks, it's a duck (Score:2)
Re:Unix cannot be defined as a single thing (Score:2)
My highly subjective opinion (Score:2)
This has been done [cygnus.com]. Trust me, it doesn't make NT feel very much like Unix -- it just makes it a nicer place to work (at least, for someone familiar with the Unix command line).
For me, there are two main areas that distinguish "Unixness":
-y
Re:windowing system (Score:2)
> I wouldn't count this one as a meaningful criterion.
Perhaps, although I wouldn't know because I've never sat at either a Solaris or IRIX system that used a graphical terminal. You can do a great deal of useful work by in either one by attaching with telnet or ssh and never going through a graphical window. (Granted my experience with both is limited but I've always ssh'd into them rather than going through an attached console.)
In my mind this is another thing that separates Unix from NT. Granted there are ways to attach to NT remotely (e.g. Terminal Server and VNC) but they're not the same thing.
--
Re:POSIX, not UNIX. (Score:2)
The Cygwin command line utilities are much better and make the Windows environment a little more comfortable, and let you do useful things like ls -1 | grep 'txt$', but it still ain't Unix.
--
Re:What about native code? (Score:2)
Re: QNX (Score:2)
The Icons ran an early QNX???? All I remember about them is that my elementary schools had 3 Icon boxes and that I was *really* frustrated in grade 7 because the BASIC interpreter was incompatible with Commodore 64 BASIC (I was pretty naive back then
Dana
Re:NT not Unix, though A/UX was much closer. (Score:2)
Re:Actually I give a rip. (Score:2)
POSIX compliancy has nothing to do with all utilities being the same. They are compliant about a sub-set of options. They share their own features. What's your point?
Re:Microsoft UNIX NT (Score:2)
> full implementation of a unix shell,
> filesystem, and command line utilities, it
> could be argued that NT would be, indeed, a >UNIX.
Yes, by people who don't understand the difference between UNIX(tm) and Unix-like, along with the fundamentals of what a Unix like OS does.
That's technically not true (Score:2)
You can easily change a single field location in
Actually I give a rip. (Score:2)
Linux has been able to allow me to use shitty hardware that NT just plain wouldn't run on (well ok the new versions of NT I had a CD of NT 3.1 and it worked on my machine but I took it off 2 hours later). A GUI interface is nice but it dosn't make up for the lack of efficiency and power that make NT evil.
What about native code? (Score:2)
I think that C++ is closest to what you could consider to be "crows platform" than almost anything: there is a ANSI standard, and a compiler for almost any system. I routinely write and run programs between win32 and linux all the time and never see a problem. Plus my code is much faster.
Re:The only UNIX is Linux (Score:2)
Maybe Sun doesn't want to "get it" yet, because they're still making lots of money with their _increasing_ market share! (besides which, Linux is terribly immature compared to Solaris, HP-UX, and so help me, AIX)
what is unix? (Score:2)
the same design elements. Sure, you can
stretch Windows so that it superficially
resembles Unix, but you cannot recreate
the startling formal elegance of a unix
system just by ading ls.exe, grep.exe,
and awk.exe to your c:\winnt\system32
directory.
The thing about Unix that is most clear,
that sets it apart from other OS's, is
its well thought-out design. It was
noticably not designed so that any
newbie could use it. I'm sure that Microsoft
came to realize the high cost of 'newbie usability'
when it had to resort to releasing another
successor to Win98 instead of merging the
9x and NT OS lines with the release of 2000.
Porting -- how hard really ? (Score:3)
Provided you are working high level, cross-platform APIs ( which should behave the same on all UNIXs ), and you don't try to code to several different APIs [1] then I don't see why it should be so hard. There are differences in the way different UNIXs handle many things [2] but there are toolkits like Qt and glib that take care of the low-level portability stuff and provide their own data-types and functions.
Just for fun, I grepped for #ifdef directives in krn and there were hardly any ( and the ones I saw weren't about portability issues ).
[1] this is why the vim code is so complex -- they are simoultaneously coding for motif, gtk, athena, ncurses, and win32 without using any high level portability tools ( because there's none that are portable across all target platforms ).
[2] An example -- many C++ compilers still have either nonfunctional or incomplete STL implementations. Another example -- some UNIXs ship with different DBMs ( ndbm,dbm,gdbm ).
Misguided Question (Score:3)
Well, not totally, but there are so many errors and misconceptions in the question I'm not sure how to answer.
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.
Wrong. Well-written programs can be easily ported from one unix to another. The problem is that many programs are written by people who have a relatively poor understanding of how to write portable code, and no idea how to distinguish the C standard, the POSIX standard, stuff that's not POSIX but almost universally available on Unix and Unix-like systems, and stuff that is specific to a particular implementation.
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.
None of which has anything to with writing portable code. For example, the C interface to the file system (fopen(), fprintf()) and posix interface (open(), read(), write()) make the underlying file system transparent. Of course, if you're writing a tool to manage a cluster, it's going to be implementation specific.
The differences between the different kinds of UNIX seem to be as great as the differences between any particular implementation and other OSs.
Sorry, you've obviously never actually had to write programs that worked on a wide variety of systems. I used to work on a large product that ran on a variety of Unix systems, OpenVMS, and NT. IIRC, the only difference between the Unices was different options to mmap() and dealing with an old version of SunOS that didn't implement POSIX signals quite correctly. (Of course, there were many differences to the system headers, but those are supplied by the vendor, and are there precisely so that you don't have to worry about internal differences.) FWIW, the OpenVMS version was pretty easy, because even the the system calls were totally different, most of the concepts mapped pretty well. NT, on the otherhand, was a complete pain in the ass.
Now obviously, one *can* write code that is specific to a particular Unix implementation. And noone will argue that at the admin level, things are aren't chaos.
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?
No, because you haven't changed the syscall interface. Cygwin comes a lot closer, but was also a lot more work than what you've proposed.
unix tools for win32 (Score:3)
You'll find bash, grep, cygwin, emacs
They've got some nice things there, look at geoshell [geoshell.com]'s screenshots, you wouldn't believe it's windows.
The tight coupling between C and Unix (Score:3)
You are completely correct in that statement, but it has nothing to do with C or Unix. The evolution, expandibility, and scope of the two systems in question has been in no way restricted. Unix has continued to expand and evolve well beyond the original scope of the C language as it eventually was defined in the ANSI standard. Likewise, C is considered the most portable language ever written, with implementations for just about every platform that has a compiler, and it has continued to evolve and be expanded past the original Unix API. It has even been expanded to include object support in C++, which was in turn used to write BeOS, a fact I'm sure you are no doubt aware of, given your handle.
So, if you have a legitimate complaint, by all means voice it, but otherwise, keep the FUD to yourself, K?
(Note to moderators: Before moderating this down as "Flamebait", check out this guy's posting history. He makes rabid Linux supporters seem tame by comparison.)
MS Unix (Score:3)
Seriously, while you're at it, you should ask exactly what Windows is. It's in the same boat - there's several flavors of a single OS that really don't have much in common. Windows CE and Windows NT don't share much except a start button, when it comes down to brass tacks.
Actually.. (Score:3)
so I could be mistaken, but as far as I remember
you have to pay someone (The Open Group?)
for the right to call something Unix.
It involves certification.
I've heard that it needs to have evolved from
the UNIX-codebase, but this doesn't make very
much sense, as it would be impossible to
write a new Unix from scratch, but still conforming to the Posix-standards, and being
source-compatible with the tradional Unix-variants.
Perhaps someone can enlighten me here, but
would it be possible to pay that organization
for certification of Linux?
Not that I think it would matter, because Linux
is now bigger than Unix anyway, and it seems very
important for other Unixvariants to include some
sort of compatibility layer to be able to run
Linuxbinaries.
I did think it mattered 2 years ago though.
Re:Simplicity, consistency and design (Score:3)
Being a long time Unix and Windows developer, I don't see any advantage to the developer to having one ioctl() that works with all devices. While it makes sense on the kernel (one api to export), it is total nonsense for the end developer.
type 'man ioctl' : There is absolute no useful information given. It's a generic function and the developer must explictly know what kind of device he is talking to and somehow find the right parameter values to pass in to make it do what he wants. ioctl documentation can never be complete.
I would argue that it's better to have more functions that are strongly typed and can be documented seperately. If the developer want's abstration, let him build it into his application - don't force it on them.
Re:What makes Windows a Window ? (Score:3)
But don't just go by my word. Go spend a few K on a Windows NT server licence, hardware, and documentation, then play with it. You'll know it's Windows because it feels "right," and because it flashes its monitor a very pretty sky blue to let you know it wants your attention. Surveys say that 60% of everyone's favourite colour is blue.
---
Re:MS Unix (Score:3)
you mean apart from the fact that CE's kernel is based on NT's, and that Windows CE basically supports 95% of the Win32 APIs?
What makes Windows a Window ? (Score:3)
Money__ asks: "Since there are now so many different flavors of Windows out there (1.0, 3.1, 95, 98, NT, 2K , etc...) what do they all have in common that lets these all be called Windows? Programs written for one flavor of Windows 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 Windows seem to be as great as the differences between any particular implementation and other OSs. Could one port all the standard GUI utilities to GNOME, clone one or two of the popular GUI features, set up the directory structure in the standard Windows layout and call it WINDOWS/UNIX?"
Hmmmmmm
_________________________
Microsoft UNIX NT (Score:3)
NT will never be Unix... (Score:3)
First is the security issue. Unix has the concept of a superuser (root). NT has role-based security. "Administrator" is not special other than having more rights than user accounts, including the right to manager user rights.
The key differences are that an NT Administrator cannot open any NTFS file regardless of modes, as a Unix superuser can. Also the Administrator account cannot arbitrarily pose as other users. There is no working setuid() call. (POSIX requires setuid to exist, but it doesn't have to work... it may return EPERM unconditionally. That is just what Microsoft's POSIX subsystem does.)
Second is the executable file format. Most modern OSes have standardized on ELF. NT is one of the holdouts, still using PE (a variant of COFF). Shared libraries on NT (i.e. DLLs) are loaded and relocated by the OS, not in user space as ELF shared objects are. And DLLs have annoying limitations, like requiring data symbols to be imported/exported.
Third, file semantics on NT are tailored for Win32. Ever try to remove/rename a NTFS file while it is open in some process? You can't. On Unix, linking and unlinking of open files is permitted, and many utilities depend on that behavior.
While it may be possible to certify NT as "POSIX-compliant" (or even get Unix branding, I don't know), it will never work truly like a Unix system. There are just too many core differences.
The UNIX Philosophy (Score:3)
The philosophy is a result of more than twenty years of software development and has grown from the UNIX community
instead of being enforced upon it. It is a defacto-style of software development. The nine major tenets of the UNIX
Philosophy are:
1.small is beautiful
2.make each program do one thing well
3.build a prototype as soon as possible
4.choose portability over efficiency
5.store numerical data in flat files
6.use software leverage to your advantage
7.use shell scripts to increase leverage and portability
8.avoid captive user interfaces
9.make every program a filter
The Ten Lesser Tenets
1.allow the user to tailor the environment
2.make operating system kernels small and lightweight
3.use lower case and keep it short
4.save trees
5.silence is golden
6.think parallel
7.the sum of the parts if greater than the whole
8.look for the ninety percent solution
9.worse is better
10.think hierarchically
File System (Score:4)
I can access my printer as a file, my serial ports as a file, my memory as a file. Heck, I can mkfs
NTFS and VFAT don't have symlinks and the hardware is up-front and ugly (ever try moving an app from C: to D:?). I'm sure there's a lot more, but these things alone are horrible. What happened to device abstraction, that I have to track my hardware when naming files?
-Paul Komarek
I can't believe it's not butter (Score:4)
UNIX encompasses more than just a set of API's, and user shells. UNIX has more to do with an OS design philosiphy, than with any particular implimentation. At the outset, UNIX strives to provide an environment made of small utilities that can easily be used together to accomplish a task. This is true from the kernel design, to the typical C API's, out to the actual user environment. From a kernel perspective, most UNIX's have a virtual file system, virtual memory system, and a process swapper. There is much more than this, but these are the three main components. By utilizing features of each of these basic parts, it is possible to implement inter process communication(Pipes, shared memory, etc), security(mostly via the VFS, since most everything in UNIX is seen as a file), and Time sharing(via the process swapper).
The next layer would be the C libraries that most UNIX's come with. While not directly tied to the OS itself, most C libraries will heavily reflect the OS they live on, since they are the common gateway to make sys calls, the main way to call system functions. It is with system calls that a program can interact with files, and access system resources. The OS will handle the scheduling and access control from behind the scenes. The C library is a way to ask for resources.
But, what most people think of when they think of UNIX, is the user environment. Unfortunately, this is missleading. Everything from Windows to OpenVMS, to OS/390 MVS can be made to look and smell like UNIX, but that doesn't make them UNIX.
What the user sees is a simplified(if you can believe that grep, sed, and awk, ad nauseam are simple
The moral of the story is that UNIX really is a "handle" that is used to encompass an approach to OS design. UNIX is a way of viewing how things should be shared, and managed. That is why UNIX runs on almost every platform. UNIX is really a memme that dictates how system resources are controlled, and not one of how a system should be architected from a hardware perspective. UNIX is a way for multiple users to access a single system, in quasi-realtime , interactive fashion. It lays out such things as scheduling, Access Control architecture, and resource presentation. If an OS follows this design philosophy, than that makes it more a UNIX, than what it's user shells look like.
That is why Linux is a UNIX, without having any blessed UNIX C code in it. It's an architecture built on the UNIX philosophy. Just remember to never let a purist hear you call Linux UNIX though. That, unfortunately, is a matter of religion, best left for another discussion.
What makes a system Unix? (Score:4)
A Philosophy (Score:4)
I've been working with Unix now for 20+ years. I've worked in the kernels of Cray Super Computers and been driven batty by a BSDish system running on a no name box for a network logger. The equipment has ranged from a 386 that took 5 minutes to boot Linux to SGI super computer cluster. And there are a few things that they all had in common. These common "features" are, in my not so humble opinion, what makes something "Unix".
For that matter, the user can't tell the difference between an IDE cdrom and a SCSI cdrom.
While API is important, and I wouldn't want to give up my X windows, or bash/tcsh I've run on Unix boxes where those are different or missing. In some cases my tools of choice were missing and I had to bootstrap 'gcc' into place and from there I added the extra tools (sed/awk/tcsh/bash) that made my life comfortable.
Unix is a style. A way of solving problems. We don't think in terms of "monolithic (Office)" programs that do almost what we want, but instead we think in terms of solving a piece of the problem, chipping away till there is nothing left. And in the process we find that we have a dozen new tools that people will use in ways we never considered.
PERL was never intended to be a webserver, but the tool is so powerful that it now is. That and much more. Every tool that Unix has is used in ways that its creator never intended. Microsoft Office will never be more than what it is, What You See Is ALL You Get.
I leave you with this quote then: "Like a precious metal, UNIX is being beaten and molded into whatever forms are most pleasing to the owners." -- Lee A Butler
UNIX is a trademark (Score:5)
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.
--
Simplicity, consistency and design (Score:5)
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.
Serious followup (Score:5)
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.
The real definition (Score:5)
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.
My Momma Always Said... (Score:5)
--
Unix cannot be defined as a single thing (Score:5)
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 [hex.net]. 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."
If it looks like a duck and quaks, it's a duck ... (Score:5)
Also, 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 ...
Blame Win32 (Score:5)
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.