In a message to the zfs-discuss list, he says that "the essence of [the issue]" was that Apple and Sun couldn't come to mutually agreeable terms on a license.
That is, assuming that having the file system and the volume manager tied to each other is a good thing.
I think I can come up with a bunch of reasons for why this is a pretty terrible idea and why modularity here is
a good thing.
Re: That's true for any licensee - in fact, Net App could adopt ZFS today and receive the same protection. The port is done to FreeBSD, the OS on which Net App's filers are built.
Last I checked NetApp was using some NetBSD-derived components in their Filer OS.
OK, to be fair, ONTAP Classic, while it has a fair bit of BSD code in it (some commands, the networking stack, etc.) isn't built on anything that matches "*BSD", so the person to whom you're replying is overstating the case. ONTAP GX, however, is FreeBSD-based.
I have heard (from mailing list) that Finder on OS X, including SL (Cocoa) does some block level stuff while emptying trash
Good luck with that over SMB and NFS (and, yes, Finder works over SMB and NFS). Whoever told you that was, to use the technical term, "completely full of shit" (unless you misinterpreted what that person said); even if it specifically checks for HFS+, it'll have to ask the superuser's permission to do "some block level stuff":
$ df/ Filesystem 512-blocks Used Available Capacity Mounted on /dev/disk0s2 311909984 280623864 30774120 91%/ $ ls -ld/dev/disk0s2 brw-r----- 1 root operator 14, 2 Oct 11 17:37/dev/disk0s2
unless it does some fcntl and that does "block level stuff" inside the file system - which doesn't count here.
Now, what the Finder does do for "secure remove" is the same stuff srm does (at least at one point it actually ransrm, as I remember), and srm Doesn't Do What You Might Think It Does on copy-on-write file systems such as ZFS - if you overwrite a file's contents N times before removing it, that doesn't do any good on a COW file system, because the old data isn't overwritten, new blocks are allocated when the write is done, so the old data is still there until the old blocks are released (which won't happen until they're no longer in any snapshots) and are reused (which could also take a while). Yes, one could do that with an fcntl, or some other way to say "snapshots be damned, I want this data gone, even if I later want it back", at least for a local file system (that wouldn't help you with, say, a NetApp NFS server, as WAFL is also a COW file system, and there's no "please make sure this data isn't preserved anywhere" NFS file removal operation).
Hopefully, whatever Apple develops next will. It would really suck if the only persistent way to refer to a file was its path.
In Mac OS X, the only guaranteed persistent way to refer to a file is its path. Some file systems have persistent file IDs, but not all the file systems that Apple ships do. The main local file system does, but there ain't no such guarantees about, say, SMB or NFS.
HFS+J case sensitive is essentially a modified UFS2.
Citationneeded. (Executive summary: no, they're not, the on-disk format is completely different. And, yes, that paper applies to HFS+, whether journaled or not, and whether it's case-sensitive HFSX or not.)
It's not like AT&T doesn't do this as well. I have the exact same problem on my AT&T sony ericsson 850a.
No such problem with an iPhone 3G/3GS on AT&T. Perhaps Verizon didn't like Apple telling them they couldn't control who got to use which (non-cell-network) features on the phone, and AT&T was willing to put up with that horrible imposition on their prerogatives.
Even if Verizon doesn't refer to it as the iPhone killer, all the pundits and bloggers hungry for pagehits, will. This only helps advertise iPhone and is detrimental to Verizon phone's introduction.
Has any device touted as an "XXX killer" ever managed to kill XXX, for any value of XXX?
(posted from an iPhone)
I might post from my iPhone, too, if iPhone OS 3.x's keychain would sync with Mobile Me's keychain (and thus OS X's keychain).
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.
Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.
(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)
Why did this work for Apple? B/c it let them build off a base system that worked pretty much everywhere, and focus on the quality and other aspects of the system their users care about instead of having to worry about all the nitty-gritty details of writing and supporting an entire operating system and all the utilities that come with it.
Actually, Apple pays a significant number of people to "worry about all the nitty-gritty details of writing and supporting an entire operating system and all the utilities that come with it" - some parts of OS X might not be much modified from the upstream BSD version, but, for example, the kernel has some FreeBSD bits in it but is developed independently, and the same is true of libc (well, libSystem, as it's called).
But remember, Apple didn't just use their own stuff - they took an open source project (FreeBSD) and built their stuff on top of it; in the process they created two more projects - Darwin and OpenDarwin - to encapsulate the open source nature of the underlying system.
Well, to be more a little more precise, Apple bought a company (NeXT) that had taken an open-source project (Mach) and a non-open-source-at-the-time project (BSD - not open source as it included AT&T-licensed code) and built their stuff on top of it, and then took NeXT's stuff, updated it with {Free,Net}BSD code (which, by that time, had become open-source), and continued to develop it (both the open-source stuff and the non-open-source stuff atop it).
1) USB flash drives use FAT16 or FAT32 not a Mac OS X filesystem. They are implemented as filesystem plug-ins.
Yes, msdosfs is a kext (loadable kernel module), but that doesn't affect the speed. AFP is a kext, and it was developed by Apple, so I think most people would consider it a Mac OS X file system.
However, as one might infer from two file systems having been mentioned, OS X comes with multiple file systems that plug into its (BSD-flavored-but-with-extra-cinnamon:-)) VFS layer. I guess if any file system were "the" OS X file system, it'd be HFS+ - but, as you note, USB flash drives aren't HFS+ (unless you explicitly reformat them as HFS+, if Disk Utility or newfs_hfs allows that).
2) Encrypted "volumes" are disk images; handled in userspace I believe...
Yes, there's a userland helper to which the in-kernel stub "disk" driver for disk images communicates.
3) WebDAV generally sucks (iDisk) and I never was a fan of it. still prefer FTP. FTP and WebDAV are both filesystem plug-ins which causes more trouble than they are worth-- not to mention loads a ton of code into the kernel; risking stability and security. Userspace would make MUCH MORE SENSE;
...which is why most of ftpfs and webdavfs are, in fact, in userland. (webdavfs's kernel stub has about 6500 lines of code, including comments and header files; ftpfs's kernel stub has the exact same number of lines of code as the NFS client code, which shouldn't be surprising as it is the NFS client code - there's a userland NFS server that acts as an FTP client.)
The article speaks of a "31-bit compatibility mode" in z/OS, but that's a mode that allows it to run on the 31-bit-address/32-bit-data pre-z/Architecture machines. Dropping that would be the equivalent of Windows 8 requiring x86-64 but still running 32-bit apps, or {pick your distribution} dropping its i386 version but still supporting 32-bit apps, or OS X 10.n, for some value of n > 6, running only on x86-64 Macs but still running 32-bit apps, or....
The article also quotes somebody as saying "Migrating in-house applications onto z/OS is almost like Y2K all over again."; I'm not sure what they mean by that - I'd be a little surprised if 32-bit-data/{24,31}-bit-addressing apps didn't largely Just Work on 64-bit z/OS.
VMS also has a similar feature when you press ^T which I find myself using all the time.
I wonder whether they picked it up from TOPS-20 - which was based on Tenex; BSD got ^T from Tenex.
As someone who has been using FreeBSD as their desktop OS for several years now, I can't believe I didn't know about it in FreeBSD!
It's also in the other *BSDs and in Mac OS X; I'm not sure whether all of them default to having the "status" character set to ^T, so I'm not sure whether they all default to having ^T work, but, if they don't default to setting the "status" character, you can do "stty status '^T'" to set it.
Some of the ^T output is handled inside the tty driver, so that shows up in response to ^T even if the foreground job isn't catching SIGINFO.
For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.
Isn't this an internal feature of their cp implementation?
No. The fact that ^T sends SIGINFO, just as ^C sends SIGINT, is a feature of the "tty driver" (standard tty line discipline). The fact that a particular program catches SIGINFO and prints a progress report is a feature of the program.
I don't see what this has to do with the kernel...
The standard tty line discipline referred to above is in the kernel.
Speaking as a user, can we get statically linked libraries?
Not if the library with which you're linking depends on another component that does not supply a stable ABI.
For example, on Solaris and Mac OS X, the system call interface (the set of available system call traps, the arguments to those traps, and the sequence of such traps used to perform certain higher-level operations, such as "look up a host name") is *NOT* guaranteed to remain the same from release to release; the stable interfaces are the APIs in libraries such as libc/libSystem.
Windows is the same. Windows OT (95, 98, Me) and Windows NT (3.x, 4.0, 2000, XP, Server 2003, Vista, Server 2008, 7, etc.) have very different implementations of the Win32 API/ABI, and the implementation might even change from release to release (consider that the GUI sat atop a server in NT 3.x and atop kernel graphics drivers in 4.0 and later).
So if the vendor were to supply a statically-linkable version of the library, that would leave open the possibility of building an app that the vendor cannot guarantee will work the same on all releases. I don't know whether Sun decided to allow that, but Apple and, I think, Microsoft didn't (they probably didn't want to have to deal with whining from developers of apps such as that, and users of those apps, when the app failed to work on a new OS release).
Apple also hosts and continues to support CUPS, the Open Source printing system, a project they bought from the developer that owned it. http://www.cups.org/
...and they hired said developer while they were at it.
And releasing GCD, gentlemen, is another master stroke by Apple, just like WebKit, Bonjour, LLVM, the list goes on, to share knowledge and advance technology by merit, not by forcing it down your throat thanks to the monopoly you have been handed.
Or because all of those things were originally developed outside of Apple, and even they don't have enough magic fanboy dust to deflect the bad karma that comes from appropriating open source software without giving it back.
So who was it that originally developed GCD and the code to Bonjour?
That is correct, but there is a standard way of determining the type of a file without tracking it: the 'file' command (which uses metadata stored in/etc/file/magic).
(We're talking about Mac OS X, so that's/usr/share/file/magic.)
file uses heuristics to try to guess the file format; most of the heuristics are encapsulated in the magic file. A lot of the heuristics are based on unique or pretty much unique magic numbers, so they're good enough to identify a lot of file types (and Konqueror, as I remember, uses magic as one way to identify file types). They might not be able to identify all file types reliably, however, so they might not be sufficient.
I don't, because I didn't find anything about them in the 2008 Single UNIX Specification, although perhaps I didn't search for them correctly.
I suppose related features like ACLs could help drive more widespread adoption of xattrs
The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.
(though in the kernel the two features are enabled separately, I believe...)
File name extensions are definitely not the UNIX way. They are the CP/M way, copied later by DOS, then by Windows, then by UNIX graphical environments such as KDE, GNOME, and Mac OS X
(Actually, CP/M picked them up from various DEC OSes, such as TOPS-10, so they're older than that.)
And KDE, and possibly GNOME, also use file-style mechanisms to identify files based on their content; when my main desktop was FreeBSD+KDE, my PDFs, for example, had no file extension (so that the file names didn't have an ugly ".pdf" at the end), but I could double-click on them to open them. When I moved to OS X, I had to put the ".pdf" back (at least I can tell the Finder not to bother me by showing it).
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename.
That's because "the under-the-hood UN*X running any of them" doesn't know about the file manager, Portable Document Format, or double-clicking on documents. The "under-the-hood Windows kernel, kernel.dll, and low-level graphics and widget layer" that the Windows desktop is built on doesn't know about that sort of stuff, either.
It's very, very unfortunate that Mac OS X is now reverting to the primitive CP/M way. It causes a loss of essential functionality that Mac power users have always depended on: to know that a document will always be opened in the application with which you've created it.
Well, functionality that some users have always depended on. Apparently, other users have at least wanted to have documents opened by the standard viewer for that document type, regardless of the application with which it was created. I.e., I think this is a case where particular people can argue passionately in favor of the system working the way they like, convinced that it's the "right" way; unfortunately, once you have two groups of people, each convinced that their way is the "right" way, and the two ways are different, you might have to choose to piss one of the two groups off.
Slashdot Mirror
In a message to the zfs-discuss list, he says that "the essence of [the issue]" was that Apple and Sun couldn't come to mutually agreeable terms on a license.
That is, assuming that having the file system and the volume manager tied to each other is a good thing. I think I can come up with a bunch of reasons for why this is a pretty terrible idea and why modularity here is a good thing.
And some other people might disagree with your reasons.
Re: That's true for any licensee - in fact, Net App could adopt ZFS today and receive the same protection. The port is done to FreeBSD, the OS on which Net App's filers are built.
Last I checked NetApp was using some NetBSD-derived components in their Filer OS.
Check more recently, please.
OK, to be fair, ONTAP Classic, while it has a fair bit of BSD code in it (some commands, the networking stack, etc.) isn't built on anything that matches "*BSD", so the person to whom you're replying is overstating the case. ONTAP GX, however, is FreeBSD-based.
None of this matters: Apple is dying. It's a matter of record.
Does Netcraft confirm it?
I have heard (from mailing list) that Finder on OS X, including SL (Cocoa) does some block level stuff while emptying trash
Good luck with that over SMB and NFS (and, yes, Finder works over SMB and NFS). Whoever told you that was, to use the technical term, "completely full of shit" (unless you misinterpreted what that person said); even if it specifically checks for HFS+, it'll have to ask the superuser's permission to do "some block level stuff":
unless it does some fcntl and that does "block level stuff" inside the file system - which doesn't count here.
Now, what the Finder does do for "secure remove" is the same stuff srm does (at least at one point it actually ran srm, as I remember), and srm Doesn't Do What You Might Think It Does on copy-on-write file systems such as ZFS - if you overwrite a file's contents N times before removing it, that doesn't do any good on a COW file system, because the old data isn't overwritten, new blocks are allocated when the write is done, so the old data is still there until the old blocks are released (which won't happen until they're no longer in any snapshots) and are reused (which could also take a while). Yes, one could do that with an fcntl, or some other way to say "snapshots be damned, I want this data gone, even if I later want it back", at least for a local file system (that wouldn't help you with, say, a NetApp NFS server, as WAFL is also a COW file system, and there's no "please make sure this data isn't preserved anywhere" NFS file removal operation).
Hopefully, whatever Apple develops next will. It would really suck if the only persistent way to refer to a file was its path.
In Mac OS X, the only guaranteed persistent way to refer to a file is its path. Some file systems have persistent file IDs, but not all the file systems that Apple ships do. The main local file system does, but there ain't no such guarantees about, say, SMB or NFS.
Citation needed.
HFS+J case sensitive is essentially a modified UFS2.
Citation needed. (Executive summary: no, they're not, the on-disk format is completely different. And, yes, that paper applies to HFS+, whether journaled or not, and whether it's case-sensitive HFSX or not.)
OS X is faster, more stable, more secure and JUST WORKS. Can you say ZFS kiddies? I thought you could.
...unless you want to use a file system that Apple supports, in which case you can't say ZFS.
It's not like AT&T doesn't do this as well. I have the exact same problem on my AT&T sony ericsson 850a.
No such problem with an iPhone 3G/3GS on AT&T. Perhaps Verizon didn't like Apple telling them they couldn't control who got to use which (non-cell-network) features on the phone, and AT&T was willing to put up with that horrible imposition on their prerogatives.
Even if Verizon doesn't refer to it as the iPhone killer, all the pundits and bloggers hungry for pagehits, will. This only helps advertise iPhone and is detrimental to Verizon phone's introduction.
Has any device touted as an "XXX killer" ever managed to kill XXX, for any value of XXX?
(posted from an iPhone)
I might post from my iPhone, too, if iPhone OS 3.x's keychain would sync with Mobile Me's keychain (and thus OS X's keychain).
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.
Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.
(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)
And...
Why did this work for Apple? B/c it let them build off a base system that worked pretty much everywhere, and focus on the quality and other aspects of the system their users care about instead of having to worry about all the nitty-gritty details of writing and supporting an entire operating system and all the utilities that come with it.
Actually, Apple pays a significant number of people to "worry about all the nitty-gritty details of writing and supporting an entire operating system and all the utilities that come with it" - some parts of OS X might not be much modified from the upstream BSD version, but, for example, the kernel has some FreeBSD bits in it but is developed independently, and the same is true of libc (well, libSystem, as it's called).
But remember, Apple didn't just use their own stuff - they took an open source project (FreeBSD) and built their stuff on top of it; in the process they created two more projects - Darwin and OpenDarwin - to encapsulate the open source nature of the underlying system.
Well, to be more a little more precise, Apple bought a company (NeXT) that had taken an open-source project (Mach) and a non-open-source-at-the-time project (BSD - not open source as it included AT&T-licensed code) and built their stuff on top of it, and then took NeXT's stuff, updated it with {Free,Net}BSD code (which, by that time, had become open-source), and continued to develop it (both the open-source stuff and the non-open-source stuff atop it).
1) USB flash drives use FAT16 or FAT32 not a Mac OS X filesystem. They are implemented as filesystem plug-ins.
Yes, msdosfs is a kext (loadable kernel module), but that doesn't affect the speed. AFP is a kext, and it was developed by Apple, so I think most people would consider it a Mac OS X file system.
However, as one might infer from two file systems having been mentioned, OS X comes with multiple file systems that plug into its (BSD-flavored-but-with-extra-cinnamon :-)) VFS layer. I guess if any file system were "the" OS X file system, it'd be HFS+ - but, as you note, USB flash drives aren't HFS+ (unless you explicitly reformat them as HFS+, if Disk Utility or newfs_hfs allows that).
2) Encrypted "volumes" are disk images; handled in userspace I believe...
Yes, there's a userland helper to which the in-kernel stub "disk" driver for disk images communicates.
3) WebDAV generally sucks (iDisk) and I never was a fan of it. still prefer FTP. FTP and WebDAV are both filesystem plug-ins which causes more trouble than they are worth-- not to mention loads a ton of code into the kernel; risking stability and security. Userspace would make MUCH MORE SENSE;
...which is why most of ftpfs and webdavfs are, in fact, in userland. (webdavfs's kernel stub has about 6500 lines of code, including comments and header files; ftpfs's kernel stub has the exact same number of lines of code as the NFS client code, which shouldn't be surprising as it is the NFS client code - there's a userland NFS server that acts as an FTP client.)
Yeah, they're definitely doing the guest user account wrong. They should be using tmpfs (or whatever OS X equivalent is)
There isn't one that comes with the OS. (Perhaps somebody other than Apple has done a tmpfs port or from-scratch implementation.)
MS's next action should be to compile a version of Windows that works on the Mac platform...
They already have. Which one would you like? Windows XP or Windows Vista (or, probably, Windows 7)?
The article says the retired mainframe is from 1997 so it's almost certainly a G3 or G4-based model.
If it was a G4 then replacing it with a mainframe that wasn't end-of-lifed would have entailed all the complications of migrating mainframe apps from 31-bit to 64-bit that are described in this article http://www.computerweekly.com/Articles/2003/12/15/199268/mainframe-users-face-upgrade-dilemma.htm.
The article speaks of a "31-bit compatibility mode" in z/OS, but that's a mode that allows it to run on the 31-bit-address/32-bit-data pre-z/Architecture machines. Dropping that would be the equivalent of Windows 8 requiring x86-64 but still running 32-bit apps, or {pick your distribution} dropping its i386 version but still supporting 32-bit apps, or OS X 10.n, for some value of n > 6, running only on x86-64 Macs but still running 32-bit apps, or....
The article also quotes somebody as saying "Migrating in-house applications onto z/OS is almost like Y2K all over again."; I'm not sure what they mean by that - I'd be a little surprised if 32-bit-data/{24,31}-bit-addressing apps didn't largely Just Work on 64-bit z/OS.
VMS also has a similar feature when you press ^T which I find myself using all the time.
I wonder whether they picked it up from TOPS-20 - which was based on Tenex; BSD got ^T from Tenex.
As someone who has been using FreeBSD as their desktop OS for several years now, I can't believe I didn't know about it in FreeBSD!
It's also in the other *BSDs and in Mac OS X; I'm not sure whether all of them default to having the "status" character set to ^T, so I'm not sure whether they all default to having ^T work, but, if they don't default to setting the "status" character, you can do "stty status '^T'" to set it.
Some of the ^T output is handled inside the tty driver, so that shows up in response to ^T even if the foreground job isn't catching SIGINFO.
For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.
Isn't this an internal feature of their cp implementation?
No. The fact that ^T sends SIGINFO, just as ^C sends SIGINT, is a feature of the "tty driver" (standard tty line discipline). The fact that a particular program catches SIGINFO and prints a progress report is a feature of the program.
I don't see what this has to do with the kernel...
The standard tty line discipline referred to above is in the kernel.
Speaking as a user, can we get statically linked libraries?
Not if the library with which you're linking depends on another component that does not supply a stable ABI.
For example, on Solaris and Mac OS X, the system call interface (the set of available system call traps, the arguments to those traps, and the sequence of such traps used to perform certain higher-level operations, such as "look up a host name") is *NOT* guaranteed to remain the same from release to release; the stable interfaces are the APIs in libraries such as libc/libSystem.
Windows is the same. Windows OT (95, 98, Me) and Windows NT (3.x, 4.0, 2000, XP, Server 2003, Vista, Server 2008, 7, etc.) have very different implementations of the Win32 API/ABI, and the implementation might even change from release to release (consider that the GUI sat atop a server in NT 3.x and atop kernel graphics drivers in 4.0 and later).
So if the vendor were to supply a statically-linkable version of the library, that would leave open the possibility of building an app that the vendor cannot guarantee will work the same on all releases. I don't know whether Sun decided to allow that, but Apple and, I think, Microsoft didn't (they probably didn't want to have to deal with whining from developers of apps such as that, and users of those apps, when the app failed to work on a new OS release).
Apple also hosts and continues to support CUPS, the Open Source printing system, a project they bought from the developer that owned it. http://www.cups.org/
...and they hired said developer while they were at it.
And releasing GCD, gentlemen, is another master stroke by Apple, just like WebKit, Bonjour, LLVM, the list goes on, to share knowledge and advance technology by merit, not by forcing it down your throat thanks to the monopoly you have been handed.
Or because all of those things were originally developed outside of Apple, and even they don't have enough magic fanboy dust to deflect the bad karma that comes from appropriating open source software without giving it back.
So who was it that originally developed GCD and the code to Bonjour?
That is correct, but there is a standard way of determining the type of a file without tracking it: the 'file' command (which uses metadata stored in /etc/file/magic).
(We're talking about Mac OS X, so that's /usr/share/file/magic.)
file uses heuristics to try to guess the file format; most of the heuristics are encapsulated in the magic file. A lot of the heuristics are based on unique or pretty much unique magic numbers, so they're good enough to identify a lot of file types (and Konqueror, as I remember, uses magic as one way to identify file types). They might not be able to identify all file types reliably, however, so they might not be sufficient.
I think xattrs are actually part of POSIX
I don't, because I didn't find anything about them in the 2008 Single UNIX Specification, although perhaps I didn't search for them correctly.
I suppose related features like ACLs could help drive more widespread adoption of xattrs
The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.
(though in the kernel the two features are enabled separately, I believe...)
To which particular kernel are you referring?
File name extensions are definitely not the UNIX way. They are the CP/M way, copied later by DOS, then by Windows, then by UNIX graphical environments such as KDE, GNOME, and Mac OS X
(Actually, CP/M picked them up from various DEC OSes, such as TOPS-10, so they're older than that.)
And KDE, and possibly GNOME, also use file-style mechanisms to identify files based on their content; when my main desktop was FreeBSD+KDE, my PDFs, for example, had no file extension (so that the file names didn't have an ugly ".pdf" at the end), but I could double-click on them to open them. When I moved to OS X, I had to put the ".pdf" back (at least I can tell the Finder not to bother me by showing it).
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename.
That's because "the under-the-hood UN*X running any of them" doesn't know about the file manager, Portable Document Format, or double-clicking on documents. The "under-the-hood Windows kernel, kernel.dll, and low-level graphics and widget layer" that the Windows desktop is built on doesn't know about that sort of stuff, either.
It's very, very unfortunate that Mac OS X is now reverting to the primitive CP/M way. It causes a loss of essential functionality that Mac power users have always depended on: to know that a document will always be opened in the application with which you've created it.
Well, functionality that some users have always depended on. Apparently, other users have at least wanted to have documents opened by the standard viewer for that document type, regardless of the application with which it was created. I.e., I think this is a case where particular people can argue passionately in favor of the system working the way they like, convinced that it's the "right" way; unfortunately, once you have two groups of people, each convinced that their way is the "right" way, and the two ways are different, you might have to choose to piss one of the two groups off.