I'm sorry, I honestly can't read his comment as meaning what you are describing. He was clearly talking about the fact that the hardware and software are all produced by the same company, so that the operating support for Apple's hardware is better than the support available in Linux for a generic PC. I'm not sure that this is true in every case, and it's not true for every class of hardware (Apple's support for SCSI tape is effectively nonexistent), but for most classes of hardware (video cards being the poster boy here) the best Linux support has been unfortunately problematic for me.
Lead of the FreeBSD core team for most of the project's life.
BTW, OS X uses a Mach kernel, not *BSD.
Mach is not a kernel. Mach provides a set of services that a kernel requires, but it's a long way from a complete kernel. It's been described as a microkernel, but I don't think that's entirely accurate either. In any case, the only complete operating system I'm aware of using the Mach kernel that isn't based on BSD is GNU Hurd. If not for Hurd, Mach might as well be called "MachBSD".:)
Many BSD variants have used Mach's scheduler, memory manager, and other components, including FreeBSD and Digital UNIX. Incidentally, when I asked Kirk McKusick about it, he said Digital UNIX was the closest commercial UNIX to the final BSD release, since it was based on 4.3 Reno, the last full 4.3 release before 4.4 Lite.
OS X has much more in common with NEXTStep than FreeBSD.
NeXTStep is another BSD derivative, based on 4.3BSD. NeXTStep, and the original versions of what became OS X, used more Mach facilities than OS X does... OS X has largely eliminated Mach messaging, for example.
As far as I have been able to tell, the last NeXTSTep-derived version that still used the NeXTSTep/4.3BSD code base was Rhapsody DR2. OS X 10.0 was released with a completely new BSD code base, using the FreeBSD source tree. OS X 10.3 refreshed that code from the latest FreeBSD source tree. The Cocoa GUI API is still based on the NeXT code, of course, but Darwin is a typical BSD mongrel.
Interesting. It wouldn't have occurred to me that they would expose the contents of the C include files as part of the D runtime, and translate the actual include files into D. Wouldn't it be better to implement the runtime exposed to the D application in a mixture of C and D, with C wrappers around the actual library calls? It would certainly make a port significantly easier!
So essentially, OSX runs every Linux application except for the ones it doesn't run.
OSX runs essentially every UNIX application. Linux applications that depend on Linux-specific features aren't UNIX applications. Do those Linux-only applications run on FreeBSD, Solaris, or AIX?
you'd better not claim OSX can run *every* Linux app.
Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive.
It's no different than distributing ZIP files that users have to unzip and then manually drag things out of.
If your packages are Cocoa-based, it doesn't matter where they're installed. They should be able to run right out of the disk image, or where you unzipped them, and all the hooks other applications and services need to locate them "just work". OS X will even re-mount the disk image if need be, when you open a file that needs that application.
It's a completely different approach than the traditional Linux one, but it's hardly unsophisticated. I take advantage of it regularly to keep my installed apps under/Local/Applications/Internet (or whatever) instead of mixed up with Apple's packages in/Applications. And I really hate people who try and subvert that, including the ones who include those stupid "drag here" links.
When I was in the NeXT world I had kind of hoped that GNUstep would take off, so that the tyranny of/usr would get broken in the rest of the UNIX world. But no use crying over spilled milk.
Now if anyone's installing packages that DO depend on where they're installed as app bundles instead of installers (and, yes, Apple DOES provide an installer framework for that use case... and it works fine for non-Cocoa-based packages), then that's an error. But I can't honestly say I have ever run into that.. usually it's the opposite situation, and I have to go in and use PAX to unpackage the installer bundle so I can get the app installed where I want it.
On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.
I've had to do that on Linux, too. When you're dealing with industrial customers, you MUST NOT update their working systems. They may have software that depends on workarounds for bugs in old packages that get broken on newer ones. I've had to have two versions of GNOME libraries and two versions of Java installed for one system, on more than one occasion.
But I never asked my users to do it. Once I figured out the problem, I built an installer to install it all outside the default prefix, and included that in the package.
I am well aware that your initial post was a strawman attack.
Let's see. Someone claimed that OS X supports the hardware it runs on better than Linux does. You responded by talking about the variety of platforms that Linux runs on. That's a perfect example of a straw man. The guy you were responding to doesn't care if OS X runs on an Alpha or Integrity server, or that old Indy you have in the back room to show how cool you are.
My response was that it doesn't matter, if you want to run on oddball hardware, you could run pretty much the same OS on all the same oddball hardware. For someone who actually uses BSD variants on a regular basis, it doesn't matter whether whether one is running FreeBSD, OS X, OpenBSD, Tru64, NetBSD, and so on... they are largely fungible, just as Ubuntu, YDL, and Gentoo are. Which is why I run FreeBSD servers and Mac desktops, and develop software on both.
I didn't complain that you can't boot a Ubuntu install CD on a Powermac, and need to get a Yellow Dog image instead. Now that WOULD be a straw man.
OSX is BSD, just as much as OpenBSD is. Yes, you have to use Apple's hardware to run OS X. That's the cost you pay to get the best UNIX desktop. I wish I could run OS X on a Thinkpad instead of my Macbook, but OS X is enough better than any Linux desktop that I've found that I'm willing to put up with it.
But that doesn't make OSX "not BSD" any more than the fact that YDL won't boot on your Thinkpad makes YDL "Not Linux".
A straw man argument is an informal fallacy based on misrepresentation of an opponent's position.[1] To "set up a straw man," one describes a position that superficially resembles an opponent's actual view, yet is easier to refute. Then, one attributes that position to the opponent. -- Wikipedia
If I thought Linux was "a fragmented mess of incompatibility" I wouldn't have been surprised that it required conditional compilation. As someone else noted, the conditional compilation was because it had been ported to Windows as well, not because it had to include distro-specific code.
Last time I looked at IRIX, it looked like System V to me.
Once you get used to real, traditional BSD, going into the OS X terminal is weird. Where's/etc/init.d and/hw? Why can't I boot -f dksc(1,5,8)sash64? No/usr/people?
peter@enclave 103 % uname -a FreeBSD enclave.in.taronga.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 peter@enclave 104 % ls/hw ls:/hw: No such file or directory peter@enclave 105 % ls/etc/init.d ls:/etc/init.d: No such file or directory peter@enclave 106 % ls/usr/people ls:/usr/people: No such file or directory
I'm kind of confused about just what you're talking about.
Whether a package is distributed as a disk image or a zip file (or a tarball, or a RAR) seems quite irrelevant to me. Are you talking about the difference between packages and bundles?
Windows doesn't even include python. If you're packaging software for Windows, and you want to use python, you can't depend on your users having any version of python, so you have to include one. And Windows library management is both primitive and highly complex. I've just submitted the final version of a Windows/Linux distribution to QA and I had a hell of a time making sure I had compatible configurations for Qt and python for everything from Windows 2000 through Windows Server 2008, and the Linux side wasn't significantly easier... we had a last minute delay because of a conflict between packages for two different Red Hat versions.
No, asking for research to be done is not trolling; claiming that OS X is *BSD when you openly admit you knew it wasn't is trolling.
A straw man argument is an informal fallacy based on misrepresentation of an opponent's position. To "set up a straw man," one describes a position that superficially resembles an opponent's actual view, yet is easier to refute. Then, one attributes that position to the opponent. -- Your beloved Wikipedia
Well, I will grant that embedding system level and environment level calls in common code is a bad idea, but it has been my experience that porting from Linux to something is easier than porting from something like "Windows" or "Mac" to Linux.
If people are writing to Apple's GUI APIs, yeh, you're not going to have much fun getting that working with GNUstep. It's a shame that GNUstep never took off. But that's not UNIX code... UNIX doesn't have a GUI.
But if you're looking for portable code, you're more likely to get FreeBSD code working on J. Random *NIX than Linux code. And an awful lot of those FreeBSD developers have Mac desktops these days.
UNIX is a family of operating systems with a native API and system call interface based on the UNIX programmer's manual, published by Bell Labs (usually the 7th edition).
I suggest, while you're out there, you look up Lites, Tru64, DragonFlyBSD, and some of the other BSD variants. You can check out the kernel code for many of the BSD variants out there, including Darwin, and let us know just how far OS X is from 4.4-Lite compared to the rest.
Oh, right, this is slashdot. Asking people to do actual research is trolling.
Oh yeh, this is slashdot alright. "When someone suggests you might be wrong, tell them they're a troll. Everyone hates trolls and accusing someone else of being a troll is the best possible way to divert attention from your own trolling".
I was at Berkeley when 4.2BSD was being pulled together, and did some work for the 4.1C release. I was one of the guys who got 386BSD to compile clean in the first place. I had a NeXTstation on my desk for several years. I was the FreeBSD handbook guy for a while. I worked with Tru64 back when it was the only fully 64-bit UNIX. I know what "BSD" and "Mach" are, better than you and better than most of the people who contributed to that Wikipedia page.
you should be aware that this is Slashdot
Yeh, I'm keeping that in mind. Thats why I'm not going to even TRY and explain just how badly you're misreading that Wikipedia page.
Didn't the summary just say that some of the system calls are missing on OS X and some macros are different?
No, the summary said that the code was written with unnecessary dependencies on obscure libraries that didn't happen to be shipped on OS X, and that it was so buggy it depended on the expansion of macros being identical on different operating systems.
I can pretty much guarantee that any program with those kinds of dependencies would have just as much of a problem porting to any other UNIX system. It wasn't a "Linux/Unix" program, it was a "Linux-only" program.
Ever tried to walk through a classroom of mac-using high-school students how to get [some non-portable piece of Linux-only code that was written with the assumption that it would only ever be run on Linux]
That's not a "package management" problem. FreeBSD has had better package management than Linux since before Linux HAD any package management system, and getting random "all the world's Red Hat" (or "all the world's Ubuntu") code running can be a pain and a half. That's a problem caused by writing code with billions of unnecessary dependencies.
Dependencies are a problem. Any sensible project manager will identify all dependencies and eliminate as many of them as they can. But "sensible project management" and Linux just don't belong in the same sentence.
I've run into the same problem on Linux, I spent a week once trying to get a set of packages and scripts working so I could package up some software to ship to customers, on Red Hat, and I ended up having to use the FreeBSD port of the package to figure out what all the dependencies were. I couldn't depend on them being able to use "yum" to pull it all together, because this was for an install that had to work on an offline system. Telling electric power utilities they had to connect their offline control system to the internet to do an upgrade was NOT an option.
Package management systems of the complexity of the ones Linux uses are a result of years of bad project management.
Yeh, there's a lot of Linux programmers who wouldn't know how to write portable code if the portable code fairy shat clue down their throats. Last decade it was SunOS programmers, the decade before that it was people who thought all the world was a VAX. The world is full of people like that.
For techies, there is no substitute for Linux or FreeBSD. (I prefer Linux, but I have friends who prefer FreeBSD.)
Ask your friends about porting Linux code from people who think portable means "it compiles on Red Hat and Suse... ship it!"
Oh, while we're on the subject, you do know that Jordan Hubbard works at Apple now, don't you?
OK, whats with this unix love? Yes it is a unix workstation, but so is HPUX. HPUX is...different. You will understand if you have ever used it.
Don't talk to me about HPUX, I'm still bitter about Alpha.
Being Unix compliant does not mean a OS is good, reliable, or stable OS.
Not being UNIX would mean that it doesn't matter how good, reliable, or stable it is... it wouldn't matter, I wouldn't be using it. I've done my time in the trenches dealing with VMS, TOPS, RSX, RTE-IV, MS-DOS, CP/M, Windows, AmigaDOS, Exec/1100, many of which were by all kinds of measures good, reliable, or stable. But dealing with different operating systems sucks rotting frog innards through used oil filters, and I'm too old for that kind of manure.
Being UNIX means that, if it also happens to be good, reliable, or stable (which it does), it's worth using. If OS X was based on Copland or even BeOS I'd still be running free UNIX on my desktop.
I was unaware that OS X runs on ALPHA, ARM, and the other 19 processor platforms that Linux supports.
You spelled that wrong. It's "BSD runs on Alpha, ARM,...". Mac OS X just happens to be the best BSD version for the desktop... and it's a much better desktop than any Linux desktop.
Linux is also UNIX on the desktop. It's just an oddball version of UNIX, with a whole bunch of extra APIs that people using Linux get used to and come to depend on, so they think writing portable code means "it runs on Red Hat and Suse" (or Debian and Ubuntu, if you're on the Left Hand path), and then when they go to port to a more standard version of UNIX, they write stuff like this:
'[Building a runtime library] exposed a lot of conditional compilation issues that had no case for OSX. I found that Linux has a bunch of API functions that are missing in OSX, like getline and getdelim, so some of the library functionality had to revert to more generic code for OSX. I had to be careful, because although many system macros had the same functionality and spelling, they had different expansions. Getting these wrong would cause some mysterious behavior, indeed.'
If you're writing code that depends on the expansion of system macros, or if you're depending on obscure Linux-only functions, you're writing unportable code. What really bothers me is the idea that someone writing a Linux-only program would already have run into situations where they had to conditionally compile code. Has Linux really fragmented that much?
Slashdot Mirror
I'm sorry, I honestly can't read his comment as meaning what you are describing. He was clearly talking about the fact that the hardware and software are all produced by the same company, so that the operating support for Apple's hardware is better than the support available in Linux for a generic PC. I'm not sure that this is true in every case, and it's not true for every class of hardware (Apple's support for SCSI tape is effectively nonexistent), but for most classes of hardware (video cards being the poster boy here) the best Linux support has been unfortunately problematic for me.
Who the hell is Jordan Hubbard?
Lead of the FreeBSD core team for most of the project's life.
BTW, OS X uses a Mach kernel, not *BSD.
Mach is not a kernel. Mach provides a set of services that a kernel requires, but it's a long way from a complete kernel. It's been described as a microkernel, but I don't think that's entirely accurate either. In any case, the only complete operating system I'm aware of using the Mach kernel that isn't based on BSD is GNU Hurd. If not for Hurd, Mach might as well be called "MachBSD". :)
Many BSD variants have used Mach's scheduler, memory manager, and other components, including FreeBSD and Digital UNIX. Incidentally, when I asked Kirk McKusick about it, he said Digital UNIX was the closest commercial UNIX to the final BSD release, since it was based on 4.3 Reno, the last full 4.3 release before 4.4 Lite.
OS X has much more in common with NEXTStep than FreeBSD.
NeXTStep is another BSD derivative, based on 4.3BSD. NeXTStep, and the original versions of what became OS X, used more Mach facilities than OS X does... OS X has largely eliminated Mach messaging, for example.
As far as I have been able to tell, the last NeXTSTep-derived version that still used the NeXTSTep/4.3BSD code base was Rhapsody DR2. OS X 10.0 was released with a completely new BSD code base, using the FreeBSD source tree. OS X 10.3 refreshed that code from the latest FreeBSD source tree. The Cocoa GUI API is still based on the NeXT code, of course, but Darwin is a typical BSD mongrel.
Interesting. It wouldn't have occurred to me that they would expose the contents of the C include files as part of the D runtime, and translate the actual include files into D. Wouldn't it be better to implement the runtime exposed to the D application in a mixture of C and D, with C wrappers around the actual library calls? It would certainly make a port significantly easier!
Indeed, he said "a Mac", not "OS X".
OS X has better support for Mac hardware than Linux does for any hardware I've tried it on.
The OP did NOT offer the caveat you are now conveniently inserting.
There's this thing in English called "context". Ignoring context is a really effective way to set up a straw man.
So essentially, OSX runs every Linux application except for the ones it doesn't run.
OSX runs essentially every UNIX application. Linux applications that depend on Linux-specific features aren't UNIX applications. Do those Linux-only applications run on FreeBSD, Solaris, or AIX?
you'd better not claim OSX can run *every* Linux app.
Good thing I never made that claim.
Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive.
It's no different than distributing ZIP files that users have to unzip and then manually drag things out of.
If your packages are Cocoa-based, it doesn't matter where they're installed. They should be able to run right out of the disk image, or where you unzipped them, and all the hooks other applications and services need to locate them "just work". OS X will even re-mount the disk image if need be, when you open a file that needs that application.
It's a completely different approach than the traditional Linux one, but it's hardly unsophisticated. I take advantage of it regularly to keep my installed apps under /Local/Applications/Internet (or whatever) instead of mixed up with Apple's packages in /Applications. And I really hate people who try and subvert that, including the ones who include those stupid "drag here" links.
When I was in the NeXT world I had kind of hoped that GNUstep would take off, so that the tyranny of /usr would get broken in the rest of the UNIX world. But no use crying over spilled milk.
Now if anyone's installing packages that DO depend on where they're installed as app bundles instead of installers (and, yes, Apple DOES provide an installer framework for that use case... and it works fine for non-Cocoa-based packages), then that's an error. But I can't honestly say I have ever run into that.. usually it's the opposite situation, and I have to go in and use PAX to unpackage the installer bundle so I can get the app installed where I want it.
On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.
I've had to do that on Linux, too. When you're dealing with industrial customers, you MUST NOT update their working systems. They may have software that depends on workarounds for bugs in old packages that get broken on newer ones. I've had to have two versions of GNOME libraries and two versions of Java installed for one system, on more than one occasion.
But I never asked my users to do it. Once I figured out the problem, I built an installer to install it all outside the default prefix, and included that in the package.
I am well aware that your initial post was a strawman attack.
Let's see. Someone claimed that OS X supports the hardware it runs on better than Linux does. You responded by talking about the variety of platforms that Linux runs on. That's a perfect example of a straw man. The guy you were responding to doesn't care if OS X runs on an Alpha or Integrity server, or that old Indy you have in the back room to show how cool you are.
My response was that it doesn't matter, if you want to run on oddball hardware, you could run pretty much the same OS on all the same oddball hardware. For someone who actually uses BSD variants on a regular basis, it doesn't matter whether whether one is running FreeBSD, OS X, OpenBSD, Tru64, NetBSD, and so on... they are largely fungible, just as Ubuntu, YDL, and Gentoo are. Which is why I run FreeBSD servers and Mac desktops, and develop software on both.
I didn't complain that you can't boot a Ubuntu install CD on a Powermac, and need to get a Yellow Dog image instead. Now that WOULD be a straw man.
OSX is BSD, just as much as OpenBSD is. Yes, you have to use Apple's hardware to run OS X. That's the cost you pay to get the best UNIX desktop. I wish I could run OS X on a Thinkpad instead of my Macbook, but OS X is enough better than any Linux desktop that I've found that I'm willing to put up with it.
But that doesn't make OSX "not BSD" any more than the fact that YDL won't boot on your Thinkpad makes YDL "Not Linux".
Right... because apart from Linux, all Unices are exactly the same
That's why writing portable code requires experience.
Linux is a fragmented mess of incompatibility
Good thing I still have this in my paste buffer:
If I thought Linux was "a fragmented mess of incompatibility" I wouldn't have been surprised that it required conditional compilation. As someone else noted, the conditional compilation was because it had been ported to Windows as well, not because it had to include distro-specific code.
Last time I looked at IRIX, it looked like System V to me.
Once you get used to real, traditional BSD, going into the OS X terminal is weird. Where's /etc/init.d and /hw? Why can't I boot -f dksc(1,5,8)sash64? No /usr/people?
I'm kind of confused about just what you're talking about.
Whether a package is distributed as a disk image or a zip file (or a tarball, or a RAR) seems quite irrelevant to me. Are you talking about the difference between packages and bundles?
Windows doesn't even include python. If you're packaging software for Windows, and you want to use python, you can't depend on your users having any version of python, so you have to include one. And Windows library management is both primitive and highly complex. I've just submitted the final version of a Windows/Linux distribution to QA and I had a hell of a time making sure I had compatible configurations for Qt and python for everything from Windows 2000 through Windows Server 2008, and the Linux side wasn't significantly easier... we had a last minute delay because of a conflict between packages for two different Red Hat versions.
No, asking for research to be done is not trolling; claiming that OS X is *BSD when you openly admit you knew it wasn't is trolling.
Well, I will grant that embedding system level and environment level calls in common code is a bad idea, but it has been my experience that porting from Linux to something is easier than porting from something like "Windows" or "Mac" to Linux.
If people are writing to Apple's GUI APIs, yeh, you're not going to have much fun getting that working with GNUstep. It's a shame that GNUstep never took off. But that's not UNIX code... UNIX doesn't have a GUI.
But if you're looking for portable code, you're more likely to get FreeBSD code working on J. Random *NIX than Linux code. And an awful lot of those FreeBSD developers have Mac desktops these days.
The author was hoping that his Linux-specific code would work on OSX, but it doesn't.
Thanks for the clarification.
It sounds like he needs some more porting experience, so he knows how to avoid the Linux dependency tarpit.
Bunch of kids with a trademark in their pocket.
UNIX is a family of operating systems with a native API and system call interface based on the UNIX programmer's manual, published by Bell Labs (usually the 7th edition).
That's a *useful* definition for UNIX.
I suggest, while you're out there, you look up Lites, Tru64, DragonFlyBSD, and some of the other BSD variants. You can check out the kernel code for many of the BSD variants out there, including Darwin, and let us know just how far OS X is from 4.4-Lite compared to the rest.
Oh, right, this is slashdot. Asking people to do actual research is trolling.
Oh yeh, this is slashdot alright. "When someone suggests you might be wrong, tell them they're a troll. Everyone hates trolls and accusing someone else of being a troll is the best possible way to divert attention from your own trolling".
No, I'm not playing, sorry.
I was at Berkeley when 4.2BSD was being pulled together, and did some work for the 4.1C release. I was one of the guys who got 386BSD to compile clean in the first place. I had a NeXTstation on my desk for several years. I was the FreeBSD handbook guy for a while. I worked with Tru64 back when it was the only fully 64-bit UNIX. I know what "BSD" and "Mach" are, better than you and better than most of the people who contributed to that Wikipedia page.
you should be aware that this is Slashdot
Yeh, I'm keeping that in mind. Thats why I'm not going to even TRY and explain just how badly you're misreading that Wikipedia page.
Didn't the summary just say that some of the system calls are missing on OS X and some macros are different?
No, the summary said that the code was written with unnecessary dependencies on obscure libraries that didn't happen to be shipped on OS X, and that it was so buggy it depended on the expansion of macros being identical on different operating systems.
I can pretty much guarantee that any program with those kinds of dependencies would have just as much of a problem porting to any other UNIX system. It wasn't a "Linux/Unix" program, it was a "Linux-only" program.
Ever tried to walk through a classroom of mac-using high-school students how to get [some non-portable piece of Linux-only code that was written with the assumption that it would only ever be run on Linux]
That's not a "package management" problem. FreeBSD has had better package management than Linux since before Linux HAD any package management system, and getting random "all the world's Red Hat" (or "all the world's Ubuntu") code running can be a pain and a half. That's a problem caused by writing code with billions of unnecessary dependencies.
Dependencies are a problem. Any sensible project manager will identify all dependencies and eliminate as many of them as they can. But "sensible project management" and Linux just don't belong in the same sentence.
I've run into the same problem on Linux, I spent a week once trying to get a set of packages and scripts working so I could package up some software to ship to customers, on Red Hat, and I ended up having to use the FreeBSD port of the package to figure out what all the dependencies were. I couldn't depend on them being able to use "yum" to pull it all together, because this was for an install that had to work on an offline system. Telling electric power utilities they had to connect their offline control system to the internet to do an upgrade was NOT an option.
Package management systems of the complexity of the ones Linux uses are a result of years of bad project management.
Not all Linux software runs on the macOS either.
Yeh, there's a lot of Linux programmers who wouldn't know how to write portable code if the portable code fairy shat clue down their throats. Last decade it was SunOS programmers, the decade before that it was people who thought all the world was a VAX. The world is full of people like that.
For techies, there is no substitute for Linux or FreeBSD. (I prefer Linux, but I have friends who prefer FreeBSD.)
Ask your friends about porting Linux code from people who think portable means "it compiles on Red Hat and Suse... ship it!"
Oh, while we're on the subject, you do know that Jordan Hubbard works at Apple now, don't you?
OK, whats with this unix love? Yes it is a unix workstation, but so is HPUX. HPUX is ...different. You will understand if you have ever used it.
Don't talk to me about HPUX, I'm still bitter about Alpha.
Being Unix compliant does not mean a OS is good, reliable, or stable OS.
Not being UNIX would mean that it doesn't matter how good, reliable, or stable it is... it wouldn't matter, I wouldn't be using it. I've done my time in the trenches dealing with VMS, TOPS, RSX, RTE-IV, MS-DOS, CP/M, Windows, AmigaDOS, Exec/1100, many of which were by all kinds of measures good, reliable, or stable. But dealing with different operating systems sucks rotting frog innards through used oil filters, and I'm too old for that kind of manure.
Being UNIX means that, if it also happens to be good, reliable, or stable (which it does), it's worth using. If OS X was based on Copland or even BeOS I'd still be running free UNIX on my desktop.
I was unaware that OS X runs on ALPHA, ARM, and the other 19 processor platforms that Linux supports.
You spelled that wrong. It's "BSD runs on Alpha, ARM, ...". Mac OS X just happens to be the best BSD version for the desktop... and it's a much better desktop than any Linux desktop.
I think I've just given FreeBSD fans nightmares for months.
You don't understand FreeBSD fans, then. Most of the FreeBSD users I know have Mac desktops. Jordan Hubbard works at Apple now.
Mac on the desktop, FreeBSD in the back office, it's a sweet environment and everything "just works".
Linux is also UNIX on the desktop. It's just an oddball version of UNIX, with a whole bunch of extra APIs that people using Linux get used to and come to depend on, so they think writing portable code means "it runs on Red Hat and Suse" (or Debian and Ubuntu, if you're on the Left Hand path), and then when they go to port to a more standard version of UNIX, they write stuff like this:
If you're writing code that depends on the expansion of system macros, or if you're depending on obscure Linux-only functions, you're writing unportable code. What really bothers me is the idea that someone writing a Linux-only program would already have run into situations where they had to conditionally compile code. Has Linux really fragmented that much?