Indeed? Do you have a citation to support this claim?
There may be some X/Open standard that requires it (although I don't see any X stuff in the W-Z section of the API tables for the UNIX 98 spec), but I have not heard of any POSIX standard that requires it. (I think there may be some IEEE standard for the Motif API, but I don't think it's required to claim POSIX conformance - for that matter, there's more than one POSIX standard, so one can probably claim some degree of POSIX conformance merely by offering 1003.1 support.)
Qt is available for free even on non-Open Source OSes, but you have to buy Qt Professional Edition if you're going to make commercial (non-Open Source) software that uses Qt, regardless of whether it runs on an Open Source OS or not.
On the other hand, you can develop, on an Open Source OS with OpenMotif, commercial software that uses Motif - but you can't use OpenMotif on a non-Open Source OS, even if it's only to be used with Open Source applications.
So you can, for example, install KDE, including Qt, on a Solaris box, but you have to buy Qt Professional Edition in order to develop and sell FooWare as a non-free Qt application, even if you're only going to sell it for Linux and the BSDs, and you can install OpenMotif on a Linux or BSD box, and develop FooWare on it and sell it without having to license Motif, but you can't install OpenMotif on your Solaris box (the Solaris box I use doesn't have Motif 2.1 on it; which releases of which commercial UNIXes, if any, come with Motif 2.1?), even if you're only doing so in order to download and build OpenFoo, an open-source application that requires Motif 2.1.
It's "like" Qt in that there are restrictions on what you can do, based on whether something involved is open-source or not - but the "something" in question differs significantly between Qt and OpenMotif.
The "N" guys had a further constraint, that being that they both had dependancies on Display Postscript, from Adobe.
NeXT did, but Sun didn't - NeWS contained an PostScript implementation of its own, not any from Adobe, and NeWS was not, as I remember, a compatible superset of Display PostScript ("superset" - the PostScript in NeWS included operators to handle input events, so you could download a program to a server that would respond to keyboard and mouse events and do work on the server, rather than the client having to handle all input events).
(The latter parenthetical note brings to mind NeFS, which Brent Callahan at Sun came up with - think "PostScript with the imaging model removed and a file system model put under it", so that NeFS requests consist of PostScript programs sent to the server and interpreted by the server.)
Next, an AS/400 uses a memory model that is partly enforced by hardware, creating a control memory and a main memory. The software in the control memory (part of which can be swapped to main memory in some cases) provides an interface to applications and services that is very simular to a virtual machine. Because this is more or less enforced in hardware, there is no easy escape to facilitate a Unix style setup on this kind of machine
The virtual machine interface is, at least as I read what one of the architects (Frank Soltis) of S/38 and AS/400 said in his book Inside the AS/400, implemented largely by binary-to-binary translation; compilers generate MI code, in a very high-level instruction set, and code in the OS kernel translates it to machine code (the 3x0-ish IMPI on the CISC machines, extended PowerPC on the RISC machines) the first time it's run.
Whether this makes it possible to run OSes other than the "licensed internal code" (OS kernel) and OS/400 is another matter (although I have the impression that the "RS64" 64-bit PowerPC chip in some RS/6000's is one of the chips done for the AS/400, and just runs with tag bits turned off, so maybe it's possible).
Until very recently, Taiwan had been plagued with copyright and patent pirating and counterfeiting. Items such as watches, shoes, electronics, clothing, music, books, and computer software were unabashedly copied, the products often indistinguishable from the originals. Faced with the loss of huge profits because of these practices, foreign companies and their governments complained and called for changes to remedy this situation.
Taiwan has revised and toughened its laws related to intellectual property rights, including laws on patents, copyrights, and trademarks. Pirating still exists, but the extent of such practices has been greatly reduced. To protect your product from pirating, you should register your patents, copyrights, and trademarks in Taiwan.
...
A major revamping of Taiwan's copyright law in 1985 provided protection for authors of almost any type of original work. In 1993, Taiwan's legislature passed The American Institute in Taiwan - Coordination Council for North American Affairs (AIT-CCNAA) Bilateral Copyright Agreement, which granted even more protection to U.S. copyright holders. To register a copyright, submit an application to the copyright committee of the Ministry of the Interior. It may take three to six months before the copyright is approved.
My point is that companies providing linux applications *clearly* have the source to their own programs, and we should be advocating that they port their software to as many platforms as possible. We should *not* be advocating that they port to some non-existant "linux compatibility binary standard".
The fact that there currently isn't a Linux-compatibility binary standard neither indicates that there never will be one nor that there should never be one.
I suspect those companies would prefer that "port[ing] their software to as many platforms as possible" not mean "porting it to Red Hat and porting it to SuSE and porting it to TurboLinux and porting it to Debian and porting it to Slackware and...", and, quite frankly, I don't particularly care to dispute their preference.
The site the person to whom you replied referred was the 86open site; they abandoned that project when various x86 OSes started adding Linux binary compatibility packages, on the grounds that this was making the Linux/x86 ABI a de facto ABI, as per
With these announcements, the need for a distinct common binary standard is gone. The operating system vendors, one way or another, have chosen a common binary format -- the Linux ELF format, which is now supported on the systems of all the developers which originally joined 86open.
Unfortunately, there isn't necessary a Linux/x86 ABI; that's at least part of what the Linux Standard Base is attempting to fix.
If the LSB comes out with a reasonable standard, then the suppliers of various Linux distributions, and of other OSes, have a choice - they can make their OSes, or the Linux compatibility environments thereof if they're not Linux distributions, conform to the LSB specifications, or not. If they do, it imposes restrictions on them, but may make it more likely that some random shrink-wrapped application will run on their platform; if they don't, it allows them more freedom, but may oblige them to live with some shrink-wrapped applications not working on their OS. (Yes, this does put the burden on the OS vendor, as per your
Look, linux is a moving target, and the linux distros try valiantly to keep up. If other platforms want to continue to be binary compatible with that target, they are going to have to track it and keep up with it.
which is fine with me; the advantage of something such as the LSB, if it comes to fruition, is that it could provide one "it" to "keep up with" that's at least written down and testable. It would presumably evolve over time.)
Much better to impress upon vendors the importance of cross-platform source compatibility.
And why exactly is it important to vendors? "It's the right thing to do" may, or may not, be sufficient; they may well choose to say "fine, we just don't care, there are enough {Red Hat, LSB-compliant, whatever} platforms that we're willing not to have our software run on the other platforms".
They have the source to applications to which source is available, and the free-software BSDs, at least, do "port the software to their own applications"; see the port and packages databases. I suspect that, at least in some cases, they submit the changes to the maintainer (although I know that they don't, in some cases; a port maintainer managed to break Ethereal in an attempt to close a security hole - we only found out about it when a user complained that Ethereal wasn't working on that platform, and I ended up closing the hole in question in a fashion that actually worked).
The binary compatibility packages let those OSes run closed source applications; the "you" in "*you* fix the source to be compatible" doesn't refer to the maintainers of the platforms.
Yes, it's not that hard to do porting, but, for better or worse, not all vendors want to do that (including the QA, support, blah blah blah involved). That may well be the reason for all the "supports Red Hat Linux" stuff that provoked the creation of the site the story discusses.
(Personally, I suspect that, unless shrink-wrapped binaries disappear - which might well be desirable, but I'm not going to hold my breath waiting for it to happen - the right answer is something such as the LSB, so that you don't need a compile farm, as the redhatisnotlinux.org folks suggested, to build binaries for N different distributions. If the non-Linux-based OSes can make their Linux environments conform to such a standard, the binaries should work there as well.)
But then nothing exciting ever happens outside of the States does it?
To be fair, they did manage to mention Konrad Zuse, but not mentioning the Mark I is pretty damn bogus, as that was, as far as I know, the first stored-program general-purpose computer, i.e. the first machine of the type most if not all of us would think of as a "computer".
"Userland" is slang for the code in an OS that runs in "user mode"; the OSes on most general-purpose computers have a portion that runs in a special "privileged" mode (the exact name for which differs from machine to machine - it might be called "kernel mode", or "supervisor state", or "ring 0" on x86 machines (although, on the original Multics machines to have a "ring 0", the privilege structure was more elaborate than just "privileged mode" and "unprivileged mode")) that allows that code direct access to the machine's hardware and direct access to the memory of all processes running on the machine (that portion is often called the "kernel"), and a portion that does not run in this mode (the mode in which it runs is often called "user mode").
Yes... I know that CDE makes use of it; I'm not sure about OpenWin.
The poster to whom you're responding said "Display PostScript", but I think he meant "NeWS", which, although it was a PostScript-based window system, was not based on Adobe's Display PostScript. (The PostScript in NeWS was extended to support handling keyboard/mouse/other input events, so that a lot of the work done by a toolkit, including handling of user input, could be done by PostScript code downloaded to the display server. As far as I know, DPS doesn't support that.)
NeWS is, for better or worse, dead; CDE never made use of it (Sun'd abandoned NeWS by then), and OpenWindows no longer makes use of it.
On an internal level, Linux uses monolithic kernal which must mostally be rewritten to port it from one type of computer to another.
It is not ipso facto the case that a monolithic kernel needs to be substantially rewritten to work on different types of computers; in fact, most of the non-hardware-device-driver Linux kernel code is shared by all platforms, and I suspect even a fair bit of the driver code is shared if a given peripheral can run on more than one platform type. (The same applies to the BSDs, to SunOS 4.x, and, as far as I know, to SunOS 5.x, which also have monolithic kernels.)
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.
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?
Ever try to remove/rename a NTFS file while it is open in some process?
(grin) try this on HP-UX with a running executable... you get "segment busy".
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
the same applies to a file you have open, but they didn't prohibit that (probably because programs depended on that as a way of, for example, creating temporary files that get removed when the application exits, even if it exits because it's killed);
it makes it a pain in the neck to install new versions of software if the old version is still running (you can't just unlink the old version and install the new one, you have to rename it and then clean it up later);
with a reasonable file system salvager run on a reboot, e.g fsck, or a file system that remembers what was unlinked but not removed and removes the files on a remount, it's not an issue.
...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).
Does it have virtual consoles (Ctrl-Alt-Fx)?
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".)
Solaris was licensed from AT&T originally, so it could call itself Unix; HP-UX was implemented independently and could not call itself Unix.
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).
As for making WIndows NT into a Unix, it's already been done; for a while it was being sold as Open NT.
From what I remember, either correctly or incorrectly, NT was based off of VMS.
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.
When MS decided to slap the GUI onto it around 3.x it became a good deal more like the NT of today.
"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.
wouldn't this allow NT to trace its roots somewhere back to a true Unix?
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.
Speaking of which...would Mac OS X be considered a true Unix (I'm not sure if Darwin passes on the POSIX stuff or not)?
If
it exports a UNIX-compatible API as one of the APIs (I have the impression that you can get at it, although you may have to work harder to do so than to get at the MacOS Classic, Carbon, or Cocoa APIs);
can be convinced to give you a UNIX-compatible command-line interface (which I also have the impression it can be convinced to do);
has a UNIX-style administrative interface (which I also have the impression it does, down at the bottom - the XML-based configuration files are a bit different, but I suspect other UNIXes differ enough in their configuration files that this may not be sufficient for me to deem it not UNIX);
NT qualifies under UNIX98 branding as a Unix system when running the compatibility overlay previously known as Interix/OpenNT. Covered in this ZDNet article.
It is, however, from the stuff on Interix on the Interix Web site, a lot more UNIX-compatible than is the native POSIX subsystem on NT.
MVS has also qualified for Unix branding, IIRC.
Well, OS/390 did, 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.
Didn't
one already do that and it was called "Xenix"?
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....)
Linux however(my favorite) is not Unix because its kernel is different. The scheduling is different, the threading is different as well as the interaction between user space and kernel space and other things.
...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.
But, for all practical purposes, [Linux] looks like Unix, it feels like Unix, it smells like Unix and sounds like Unix.
...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).
There's a standard called POSIX which defines just what the core of UNIX is, including the C library, file handling, the sockets interface, that sort of thing.
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).
is a joint technical working group established to consider the matter of a common revision of ISO/IEC 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2 and the appropriate parts of the Single UNIX Specification.
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.
IIRC, what makes a brand of Unix, Unix... Is the source code has to descent from the original Unix for the PDP-7. So such variants as Linux are *NOT* considered Unix. As well, I believe the word Unix is copyrighted, and owned by AT&T (somebody tell me if I'm wrong?).
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...).
Slashdot Mirror
Indeed? Do you have a citation to support this claim?
There may be some X/Open standard that requires it (although I don't see any X stuff in the W-Z section of the API tables for the UNIX 98 spec), but I have not heard of any POSIX standard that requires it. (I think there may be some IEEE standard for the Motif API, but I don't think it's required to claim POSIX conformance - for that matter, there's more than one POSIX standard, so one can probably claim some degree of POSIX conformance merely by offering 1003.1 support.)
How?
Qt is available for free even on non-Open Source OSes, but you have to buy Qt Professional Edition if you're going to make commercial (non-Open Source) software that uses Qt, regardless of whether it runs on an Open Source OS or not.
On the other hand, you can develop, on an Open Source OS with OpenMotif, commercial software that uses Motif - but you can't use OpenMotif on a non-Open Source OS, even if it's only to be used with Open Source applications.
So you can, for example, install KDE, including Qt, on a Solaris box, but you have to buy Qt Professional Edition in order to develop and sell FooWare as a non-free Qt application, even if you're only going to sell it for Linux and the BSDs, and you can install OpenMotif on a Linux or BSD box, and develop FooWare on it and sell it without having to license Motif, but you can't install OpenMotif on your Solaris box (the Solaris box I use doesn't have Motif 2.1 on it; which releases of which commercial UNIXes, if any, come with Motif 2.1?), even if you're only doing so in order to download and build OpenFoo, an open-source application that requires Motif 2.1.
It's "like" Qt in that there are restrictions on what you can do, based on whether something involved is open-source or not - but the "something" in question differs significantly between Qt and OpenMotif.
NeXT did, but Sun didn't - NeWS contained an PostScript implementation of its own, not any from Adobe, and NeWS was not, as I remember, a compatible superset of Display PostScript ("superset" - the PostScript in NeWS included operators to handle input events, so you could download a program to a server that would respond to keyboard and mouse events and do work on the server, rather than the client having to handle all input events).
(The latter parenthetical note brings to mind NeFS, which Brent Callahan at Sun came up with - think "PostScript with the imaging model removed and a file system model put under it", so that NeFS requests consist of PostScript programs sent to the server and interpreted by the server.)
The virtual machine interface is, at least as I read what one of the architects (Frank Soltis) of S/38 and AS/400 said in his book Inside the AS/400, implemented largely by binary-to-binary translation; compilers generate MI code, in a very high-level instruction set, and code in the OS kernel translates it to machine code (the 3x0-ish IMPI on the CISC machines, extended PowerPC on the RISC machines) the first time it's run.
Whether this makes it possible to run OSes other than the "licensed internal code" (OS kernel) and OS/400 is another matter (although I have the impression that the "RS64" 64-bit PowerPC chip in some RS/6000's is one of the chips done for the AS/400, and just runs with tag bits turned off, so maybe it's possible).
And the evidence that makes this apparent is?
This Business Law in Taiwan page says
and this page on "Steps to Selling in Taiwan" (which appears to be on a US Air Force site - go figure) says:
and here's something that I infer is a translation of the copyright law itself.
The fact that there currently isn't a Linux-compatibility binary standard neither indicates that there never will be one nor that there should never be one.
I suspect those companies would prefer that "port[ing] their software to as many platforms as possible" not mean "porting it to Red Hat and porting it to SuSE and porting it to TurboLinux and porting it to Debian and porting it to Slackware and...", and, quite frankly, I don't particularly care to dispute their preference.
The site the person to whom you replied referred was the 86open site; they abandoned that project when various x86 OSes started adding Linux binary compatibility packages, on the grounds that this was making the Linux/x86 ABI a de facto ABI, as per
Unfortunately, there isn't necessary a Linux/x86 ABI; that's at least part of what the Linux Standard Base is attempting to fix.
If the LSB comes out with a reasonable standard, then the suppliers of various Linux distributions, and of other OSes, have a choice - they can make their OSes, or the Linux compatibility environments thereof if they're not Linux distributions, conform to the LSB specifications, or not. If they do, it imposes restrictions on them, but may make it more likely that some random shrink-wrapped application will run on their platform; if they don't, it allows them more freedom, but may oblige them to live with some shrink-wrapped applications not working on their OS. (Yes, this does put the burden on the OS vendor, as per your
which is fine with me; the advantage of something such as the LSB, if it comes to fruition, is that it could provide one "it" to "keep up with" that's at least written down and testable. It would presumably evolve over time.)
And why exactly is it important to vendors? "It's the right thing to do" may, or may not, be sufficient; they may well choose to say "fine, we just don't care, there are enough {Red Hat, LSB-compliant, whatever} platforms that we're willing not to have our software run on the other platforms".
And let's not forget the fungicide named UNIX (alas, www.novartis.com isn't responding, so I can't check to see whether the Novartis page cited in that item is still there).
They have the source to applications to which source is available, and the free-software BSDs, at least, do "port the software to their own applications"; see the port and packages databases. I suspect that, at least in some cases, they submit the changes to the maintainer (although I know that they don't, in some cases; a port maintainer managed to break Ethereal in an attempt to close a security hole - we only found out about it when a user complained that Ethereal wasn't working on that platform, and I ended up closing the hole in question in a fashion that actually worked).
The binary compatibility packages let those OSes run closed source applications; the "you" in "*you* fix the source to be compatible" doesn't refer to the maintainers of the platforms.
Yes, it's not that hard to do porting, but, for better or worse, not all vendors want to do that (including the QA, support, blah blah blah involved). That may well be the reason for all the "supports Red Hat Linux" stuff that provoked the creation of the site the story discusses.
(Personally, I suspect that, unless shrink-wrapped binaries disappear - which might well be desirable, but I'm not going to hold my breath waiting for it to happen - the right answer is something such as the LSB, so that you don't need a compile farm, as the redhatisnotlinux.org folks suggested, to build binaries for N different distributions. If the non-Linux-based OSes can make their Linux environments conform to such a standard, the binaries should work there as well.)
To be fair, they did manage to mention Konrad Zuse, but not mentioning the Mark I is pretty damn bogus, as that was, as far as I know, the first stored-program general-purpose computer, i.e. the first machine of the type most if not all of us would think of as a "computer".
Just out of curiosity, in what way is "the new display system" "vector based" while Display PostScript isn't "vector based"?
"Userland" is slang for the code in an OS that runs in "user mode"; the OSes on most general-purpose computers have a portion that runs in a special "privileged" mode (the exact name for which differs from machine to machine - it might be called "kernel mode", or "supervisor state", or "ring 0" on x86 machines (although, on the original Multics machines to have a "ring 0", the privilege structure was more elaborate than just "privileged mode" and "unprivileged mode")) that allows that code direct access to the machine's hardware and direct access to the memory of all processes running on the machine (that portion is often called the "kernel"), and a portion that does not run in this mode (the mode in which it runs is often called "user mode").
The poster to whom you're responding said "Display PostScript", but I think he meant "NeWS", which, although it was a PostScript-based window system, was not based on Adobe's Display PostScript. (The PostScript in NeWS was extended to support handling keyboard/mouse/other input events, so that a lot of the work done by a toolkit, including handling of user input, could be done by PostScript code downloaded to the display server. As far as I know, DPS doesn't support that.)
NeWS is, for better or worse, dead; CDE never made use of it (Sun'd abandoned NeWS by then), and OpenWindows no longer makes use of it.
It is not ipso facto the case that a monolithic kernel needs to be substantially rewritten to work on different types of computers; in fact, most of the non-hardware-device-driver Linux kernel code is shared by all platforms, and I suspect even a fair bit of the driver code is shared if a given peripheral can run on more than one platform type. (The same applies to the BSDs, to SunOS 4.x, and, as far as I know, to SunOS 5.x, which also have monolithic kernels.)
Do you have any hard evidence to support the assertion that Cisco uses the OpenBSD stack - or any BSD-derived networking stack - in their routers?
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.
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?
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
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".)
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.
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.
They don't seem to be listed on The Open Group's page listing UNIX 95-branded products, 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, a lot more UNIX-compatible than is the native POSIX subsystem on NT.
Well, OS/390 did, 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.
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....)
...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).
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
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.
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...).