mount_ftp in OS X is an add-on to Web design software? That's news to me....
...although mount_ftp gives you a read-only file system. (Read/write would probably require something fancier than a user-mode NFSv2 or NFSv3 server, as it'd need to know when you're done writing to a file so it knows when to push it back to the server.)
Note that you picked the most simple example possible. How would KDE handle a (for example) 10MB MDB database file that uses file record locking? It's certainly not going to work right over a FTP link.
The more complex usecases are exactly why Windows and OS X do not have these features (except as add-ons to web design software).
mount_ftp in OS X is an add-on to Web design software? That's news to me....
(I haven't tried doing record locking on a file over FTP, so I don't know how well it works, but I suspect the answer is "not at all". It might behave weirdly, given that mount_ftp is a local user-mode NFS server, so the NFS client code will probably either just return EOPNOTSUPP for lock requests if the mount_ftp file system is mounted with locking disabled or might try to contact the local lock manager and lock the file if it's not mounted with locking disabled - the latter is unlikely to work. EOPNOTSUPP is at least a failure mode that the application should handle, even if it handles it by saying "sorry, I can't do byte-range locking, so I can't access this database".)
I don't see why this has to be at the kernel level - why not just make programs that use kioslave functions instead of open() (or whatever)?
Because
the program you want to use might already have been made, and you don't want to have to convert it, or have somebody convert it, to use KIO (it might not even be a KDE program - neither cat nor grep are, on most systems);
your application randomly access the file (I don't see anything immediately obvious in the KDE I/O Architecture document that indicates that you can open a file and seek around in it and read from arbitrary offsets);
your application is supposed to work without KDE (and even if, as, and when a KDE version of that particular application is done, it'll still have non-KDE versions, e.g. for Windows);
etc..
Not only that, but some protocols are very slow or don't work with directories well, and wouldn't be sutable to be treated like local folders.
Which ones?
Putting this in the kernel is asking for a lot more root (and not just user) exploits.
OK, then how about just putting FUSE or lufs in the kernel and doing the bulk of the work in user space? (That's how OS X's ftpfs and webdavfs work - they have "stub" file systems in the kernel that talk to user-mode daemons; heck, the "stub" file system for ftpfs is called "the NFS client", and the user-mode daemon is a user-mode NFS server on a port other than 2049.)
And finally, everything that uses traditional system calls would have to be modified considerably or there will no doubt be many expolits found for them.
And the reason why adding a new file system type makes that true is?
arbon and Cocoa are a much better example of two completely seperate sets of APIs and development environments that work almost seamlessly in OS X. In some cases you have to work very hard to tell which one was used to make an application.
And in other cases you just have to try using Emacs keystrokes in a text field to see if they work or not - if they do, it's Cocoa, if they don't, it's Carbon, at least in Panther. (^A, ^E, ^B, ^F,, ^P, ^N, ^K, etc. work in, for example, the text box in which I'm typing this reply in the Cocoa-based Safari, but they don't work in, for example, the name field for a desktop icon, if you're editing the name in the Carbon-based Finder.)
Admittedly, that is a rather geeky test, which I suspect most Mac users wouldn't even know about, so perhaps that counts as "working very hard".:-)
There was a project called Fuse, (File system in User SpacE) that aimed to make a kernel module that would let linux users actually mount anything that the KDE I/O Slaves can handle.
Does anyone know what happened to it
Its home page moved to SourceForge. However, it doesn't itself handle stuff the KDE IOSlaves can handle; for that you'd also want the KIO Fuse Gateway.
and if there are any other projects that would do this?
Well, technically there is a VFS layer in the kernel, that abstracts the idea of a filesystem away from the implementation. So you use all the same calls for accessing ext2, reiserfs and smbfs.
Yes, I know Linux has that sort of thing, just as {Free,Net,Open}BSD do, and just as OS X does, and just as a bunch of other UN*Xes do, going all the way back at least as far as SunOS 2.0 (or "Sun UNIX 4.2BSD Release 2.0" or whatever it called itself back then).
In the big reiser4 flamewar on the kernel mailing list, there was talk of extending the Linux vfs (where the stuff belongs, rather than in any specific filesystem) with file-as-directory stuff and so on, which could help with the browsing zip files and stuff.
What "stuff" are you saying belongs there? I'm not convinced that "file-as-directory stuff", if by that you mean something that lets you look at a tarball or a zipball or... as a directory showing the files and directories in the *ball, belongs in the VFS layer.
Something that lets you mount a *ball as a file system, with the contents of the *ball as the contents of the file system, might be, but hooks to allow such a thing, and stuff that lets you look inside *balls (and do a bunch of other things as well), are available for Linux, so perhaps all that's needed in the kernel is FUSE (if AVFS is usermode code that plugs into FUSE).
I haven't looked at the webdavfs kext in Darwin 7.4 to see if it could be used to talk to usermode daemons other than the webdavfs daemon, so I don't know whether OS X already has something that could do the same as FUSE.
Some of the remote mounting could probably be done today (lufs? autofs? not sure really),
lufs or FUSE, probably, unless autofs isn't specialized towards talking to a user-mode automounter daemon.
but it probably wouldn't be as clean as it works out in KDE.
Why not? If it's done below the VFS layer, it's definitely cleaner in one sense - anything that ultimately uses open/close/read/write/etc. can use it. It might not be as clean in the sense that you wouldn't just be able to say ftp://ftp.foobar.org/pub/current-release.tar.gz to access the file in question, but if you couple it with something that lets you register a mount helper for a URI scheme (so you can find the appropriate code to handle an SMB mount for smb://hostname/..., an NFS mount for nfs://hostname/..., and so on), something along the lines of what's done in KDE could be done in a wrapper I/O library.
It's not as clean in the portability sense, as you'd have to worry about different "user-mode file system" frameworks on different OSes (even if the framework you use is the NFS client, there are probably different ways of doing setting up a user-mode NFS server on different OSes) and different ways of doing mounts of different file system types, but it's arguably cleaner from the end-user standpoint.
If you minimise Winamp, for example, it doesn't get minimised to the taskbar, but to the little launch icon. If you want to restore the Winamp window, you have to look for it in the taskbar, find that it's not there, then look at the system tray, see that it's not there either, then click on the launch icon, which will restore the window.
Is Winamp just interpreting the "minimize" request as a "close the window but don't exit" operation, and does clicking on the launch icon then somehow arrange to send an indication to Winamp that it should open a new window rather than running winamp.exe (or does running winamp.exe cause the new process to just deliver such an indication to Winamp, or something such as that)?
I.e., is that really a standard form of minimization, or is Winamp just doing something weird? If so, whilst some of the blame could be apportioned to Windows for allowing it to do so, most of the blame probably belongs to Winamp for doing so (and I suspect a perverse developer could arrange to make a UNIX+X11 application do this, too).
"or it can be minimised to one of the application launch buttons on the panels"
Windows doesn't have a "panel", nor does it have "application launch buttons". If explorer.exe is not running, applications will minimize to a mini-window (ala 3.11) but this is not a normal condition users will encounter.
Might the person to whom you're replying be referring to the quick launch thingies (or whatever they're called in Windowsland) in the task bar in NT 5.0^H^H^H^H^H^HW2K (and possibly other versions)? If so, that's not "minimized", either, as far as I know; it's sort of like launching from the icons in the panel in KDE or the Dock in OS X. I, like you, would only consider a "minimized" window to be a window that's had the "minimize" button in the title bar clicked; those shrink to the taskbar in KDE, just as they do in Windows (and shrink to the Dock in OS X).
OSX's webdav and FTP client support accessable from the finder, the analogues to KDE's FTP and webdav protocol plugins, are in reality implemented in the kernel as a filesystem implementation
...with a user-mode daemon doing the heavy lifting. WebDAV is done with a specialized kernel stub to talk to the daemon; FTP is done by mount_ftp acting as a user-mode NFS server (try capturing on lo0 while looking at a mounted FTP file system, and see the NFS traffic - don't use a filter of "port 2049", it doesn't use port 2049 because you might be running the native NFS server code).
Now, if there were a native framework (in the generic sense of "framework", not necessarily in the OS X sense) to make it easier to write user-mode NFS servers, or, for file systems where that's not sufficient (webdavfs is read/write, but I don't think WebDAV supports partial writes of arbitrary numbers of bytes to arbitrary offsets, so I think webdavfs writes to a local copy and pushes it back to the server when the file is closed, but NFSv2 and NFSv3 don't tell you when the file is closed), a standard kernel stub plus a framework for communicating with it, with the framework perhaps also handling things such as local caching of file contents (e.g. for protocols oriented towards whole-file transfer) so that it's easier to add new file systems of that sort, that'd give you the "filesystem drivers as userspace processes" mechanism you referred to.
The Windows FTP functionality I typically use works as well as the FTP functionality I typically use on most UN*Xes, including OS X, but that's because it's the same functionality I use on many of those systems, although OS X, at least, uses Luke Mewburn's ftp program other than the traditional BSD ftp program that Windows and at least some other UN*Xes use.:-)
As for OS X, it supports transparent FTP access from the command line - try man mount_ftp.
It's not fundementally different than something like NFS, or even the VFS, which allows apps to treat files on a hard-drive the same way as files on a cd-rom.
...other than not being implemented below the UN*X file API, unlike file systems plugged into the VFS that are implemented below that API layer; implementing them below that layer allows all applications, including non-KDE applications, to access the files.
I.e., bitching about copy-and-paste in X11 is getting a bit old, at least for complaints about it not working at all, even for text. Perhaps for non-text formats there needs to be a bit more work in the toolkits and applications, but, as I remember, the selections mechanism in the ICCCM does have a mechanism to register data types and to have a recipient of data find out the types in which data in a selection is available, so they can choose the "best" type (e.g., it might be available as rich text or plain text, so that a word processor would fetch the rich-text version but a terminal window would fetch the plain-text version).
(Unix has done this right since day one, which is why you don't need to put.bat on the end of your shell scripts)
...that doesn't mean that suffixes aren't needed at all on UN*X - try calling a C source file "foo.f" and see how eager GCC, for example, is to compile it:
% cat foo.f int main() { printf("Hello, world!\n"); } % gcc foo.f gcc: foo.f: Fortran compiler not installed on this system
At the desktop GUI level, some UN*X desktops, such as KDE and, I think, Gnome (and possibly CDE and others) don't require suffixes in many cases, as they do file-style file type determination by looking at the file's contents, and give the file the right icon, launch the right application when you click the file, etc., but whether that behavior can be attributed to "Unix" is another matter. At least one UN*X desktop is mainly suffix-based and doesn't do that sort of "look at the file contents" file type determination, although I guess if the file's on a file system that supports resource forks and the resource fork has the right type and/or creator code it might work.
Windows and OSX are a long way from this. They just about understand http
Umm, no, OS X definitely lets you add handlers for arbitrary URL schemes, and I infer from what others have said in replies to the original article that Windows does so as well. They don't have an IOSlave equivalent, but, at least in OS X, I'd be inclined to implement that as a user-mode NFS server, which means it'd be more general than an IOSlave, because it'd be usable by all applications, not just KDE applications (see, for example, OS X's mount_ftp, which I think might work through a user-mode FTP server with an FTP client as a back end). If possible, I'd be inclined to do it with a user-mode SMB server in Windows, although that might be less likely to work on port other than 139 or 445 (and thus less likely to run without interfering with any standard SMB server running on the machine).
The only way to get this across every single application is to include it at the filesystem level. First, the KDE developers aren't kernel hackers, so they probably don't have the expertise to write such an extension.
But do they have the expertise to write a user-mode NFS server that uses the protocol in question as the back end? There'd still be some platform-dependent crap to do the NFS mount (probably using a port other than 2049, if the platform's NFS client supports that), and there might be some file systems where that doesn't work all that well, but it might work well for many of them.
Unfortunately, NFSv2 and v3 don't have "open" operations, so read/write file systems might be a little painful if the file system protocol is oriented towards copying entire files, as you'd probably want to implement writing by writing to a local copy of the file and writing the file back to the server when it's closed. NFSv4 might help, although that'd help only on OSes with NFSv4 clients mature enough for that purpose (Linux's might be; I think Solaris 10 will have a v4 client which might be; there are v4 clients under development for the BSDs, although I don't know whether they'll end up in OS X at some point).
For access to tarballs, zipballs, and the like, read/write access would be tricky, as you easily can't update individual files in place. If you offer read-only access, a user-mode NFS server would probably work.
Now, you can call me paranoid, if you want, but just look at the number of errors that are related to this kind of hadling prtocols. While it is really nice to have all these protocols accessible in one common and uniform manner, this also looks like a road to Microsoft-like hell. It only takes one bug in one of the protocol handlers and one "link" embedded in HTML document to wreak havoc over application, desktop or even worse complete user profile.
Apple is doing this stuff (e.g. you can mount WebDAV servers), but Apple is doing it right by integrating network resources into the real VFS layer so that all applications can access them.
Yup. (Are smb: URLs in Konqueror, on OSes with an SMB client VFS, handled by a userland SMB client IOSlave, or handled by mounting the file system and accessing it through standard UN*X APIs?)
One problem with doing it in the VFS layer, though, is that you might need to stuff a VFS into the kernel. For some protocols, you might be able to use a user-mode NFS server (which is sort of the "standard" way to do a user-mode file system in most UN*Xes) instead; I don't know whether all of the "remote file access over protocols not really intended for use as remote file access protocols" file systems could be made to work that way or not. If not, it might be nice if there were some other hook into which user-mode daemons to support those protocols could be plugged, so that a kernel-mode VFS stub to talk to the daemon doesn't have to be written.
Or maybe that's two "cubes" links - one for the OS X Setup Assistant (if you can find a link for that), which, at least on machines with enough graphics horsepower, uses a rotating cube effect, and Keynote, where a rotating cube is at least one of the transition effects you can use.
All these corporate suits and devils and penguins, running around w/ rocket launchers and sniper rifles. Deathmatch, maybe some capture the flag -- it could work...
How about ice hockey? (I though I'd remembered hearing that Torvalds had suggested that Tux and Beastie play ice hockey with Bill Gates' head, but either that happened in another message or didn't happen at all.)
Next you'll say Linux should follow the Apple ][ spec.
The difference here is that Linux never attempted to be compatible with any of the Apple II OSes, but it does attempt to be a UN*X-compatible OS.
Much of Linux's strength is in _not_ being constrained by legacy APIs.
"Not being constrained by legacy APIs" in the sense that it can cheerfully break compatibility with them (a claim for which I've seen little, if any, evidence - yeah, perhaps that sort of breakage occurs on occasion, but that arguably makes it no different from other UN*Xes), "not being constrained by legacy APIs" in the sense that it can introduce new APIs for new capabilities (which makes it no different from other UN*Xes), or "not being constrained by legacy APIs" in the sense that it can introduce new APIs to supplant legacy APIs (and even that arguably makes it no different from other UN*Xes)?
Similarly, the mainframe OSes don't bother trying to have advanced graphical capabilities
So are you saying Solaris isn't a mainframe OS, or GNOME doesn't offer advanced graphical capaiblities? (NOTE: I'm not arguing here either that Solaris is a mainframe OS or that GNOME does offer advanced graphical capabilities. I leave it to you to make arguments for or against those propositions.)
Slashdot Mirror
...although mount_ftp gives you a read-only file system. (Read/write would probably require something fancier than a user-mode NFSv2 or NFSv3 server, as it'd need to know when you're done writing to a file so it knows when to push it back to the server.)
mount_ftp in OS X is an add-on to Web design software? That's news to me....
(I haven't tried doing record locking on a file over FTP, so I don't know how well it works, but I suspect the answer is "not at all". It might behave weirdly, given that mount_ftp is a local user-mode NFS server, so the NFS client code will probably either just return EOPNOTSUPP for lock requests if the mount_ftp file system is mounted with locking disabled or might try to contact the local lock manager and lock the file if it's not mounted with locking disabled - the latter is unlikely to work. EOPNOTSUPP is at least a failure mode that the application should handle, even if it handles it by saying "sorry, I can't do byte-range locking, so I can't access this database".)
Because
etc..
Which ones?
OK, then how about just putting FUSE or lufs in the kernel and doing the bulk of the work in user space? (That's how OS X's ftpfs and webdavfs work - they have "stub" file systems in the kernel that talk to user-mode daemons; heck, the "stub" file system for ftpfs is called "the NFS client", and the user-mode daemon is a user-mode NFS server on a port other than 2049.)
And the reason why adding a new file system type makes that true is?
And in other cases you just have to try using Emacs keystrokes in a text field to see if they work or not - if they do, it's Cocoa, if they don't, it's Carbon, at least in Panther. (^A, ^E, ^B, ^F,, ^P, ^N, ^K, etc. work in, for example, the text box in which I'm typing this reply in the Cocoa-based Safari, but they don't work in, for example, the name field for a desktop icon, if you're editing the name in the Carbon-based Finder.)
Admittedly, that is a rather geeky test, which I suspect most Mac users wouldn't even know about, so perhaps that counts as "working very hard". :-)
Its home page moved to SourceForge. However, it doesn't itself handle stuff the KDE IOSlaves can handle; for that you'd also want the KIO Fuse Gateway.
lufs?
Yes, I know Linux has that sort of thing, just as {Free,Net,Open}BSD do, and just as OS X does, and just as a bunch of other UN*Xes do, going all the way back at least as far as SunOS 2.0 (or "Sun UNIX 4.2BSD Release 2.0" or whatever it called itself back then).
What "stuff" are you saying belongs there? I'm not convinced that "file-as-directory stuff", if by that you mean something that lets you look at a tarball or a zipball or... as a directory showing the files and directories in the *ball, belongs in the VFS layer.
Something that lets you mount a *ball as a file system, with the contents of the *ball as the contents of the file system, might be, but hooks to allow such a thing, and stuff that lets you look inside *balls (and do a bunch of other things as well), are available for Linux, so perhaps all that's needed in the kernel is FUSE (if AVFS is usermode code that plugs into FUSE).
I haven't looked at the webdavfs kext in Darwin 7.4 to see if it could be used to talk to usermode daemons other than the webdavfs daemon, so I don't know whether OS X already has something that could do the same as FUSE.
lufs or FUSE, probably, unless autofs isn't specialized towards talking to a user-mode automounter daemon.
Why not? If it's done below the VFS layer, it's definitely cleaner in one sense - anything that ultimately uses open/close/read/write/etc. can use it. It might not be as clean in the sense that you wouldn't just be able to say ftp://ftp.foobar.org/pub/current-release.tar.gz to access the file in question, but if you couple it with something that lets you register a mount helper for a URI scheme (so you can find the appropriate code to handle an SMB mount for smb://hostname/..., an NFS mount for nfs://hostname/..., and so on), something along the lines of what's done in KDE could be done in a wrapper I/O library.
It's not as clean in the portability sense, as you'd have to worry about different "user-mode file system" frameworks on different OSes (even if the framework you use is the NFS client, there are probably different ways of doing setting up a user-mode NFS server on different OSes) and different ways of doing mounts of different file system types, but it's arguably cleaner from the end-user standpoint.
Is Winamp just interpreting the "minimize" request as a "close the window but don't exit" operation, and does clicking on the launch icon then somehow arrange to send an indication to Winamp that it should open a new window rather than running winamp.exe (or does running winamp.exe cause the new process to just deliver such an indication to Winamp, or something such as that)?
I.e., is that really a standard form of minimization, or is Winamp just doing something weird? If so, whilst some of the blame could be apportioned to Windows for allowing it to do so, most of the blame probably belongs to Winamp for doing so (and I suspect a perverse developer could arrange to make a UNIX+X11 application do this, too).
Might the person to whom you're replying be referring to the quick launch thingies (or whatever they're called in Windowsland) in the task bar in NT 5.0^H^H^H^H^H^HW2K (and possibly other versions)? If so, that's not "minimized", either, as far as I know; it's sort of like launching from the icons in the panel in KDE or the Dock in OS X. I, like you, would only consider a "minimized" window to be a window that's had the "minimize" button in the title bar clicked; those shrink to the taskbar in KDE, just as they do in Windows (and shrink to the Dock in OS X).
...with a user-mode daemon doing the heavy lifting. WebDAV is done with a specialized kernel stub to talk to the daemon; FTP is done by mount_ftp acting as a user-mode NFS server (try capturing on lo0 while looking at a mounted FTP file system, and see the NFS traffic - don't use a filter of "port 2049", it doesn't use port 2049 because you might be running the native NFS server code).
Now, if there were a native framework (in the generic sense of "framework", not necessarily in the OS X sense) to make it easier to write user-mode NFS servers, or, for file systems where that's not sufficient (webdavfs is read/write, but I don't think WebDAV supports partial writes of arbitrary numbers of bytes to arbitrary offsets, so I think webdavfs writes to a local copy and pushes it back to the server when the file is closed, but NFSv2 and NFSv3 don't tell you when the file is closed), a standard kernel stub plus a framework for communicating with it, with the framework perhaps also handling things such as local caching of file contents (e.g. for protocols oriented towards whole-file transfer) so that it's easier to add new file systems of that sort, that'd give you the "filesystem drivers as userspace processes" mechanism you referred to.
The Windows FTP functionality I typically use works as well as the FTP functionality I typically use on most UN*Xes, including OS X, but that's because it's the same functionality I use on many of those systems, although OS X, at least, uses Luke Mewburn's ftp program other than the traditional BSD ftp program that Windows and at least some other UN*Xes use. :-)
As for OS X, it supports transparent FTP access from the command line - try man mount_ftp.
...other than not being implemented below the UN*X file API, unlike file systems plugged into the VFS that are implemented below that API layer; implementing them below that layer allows all applications, including non-KDE applications, to access the files.
...and ctrl-x probably works in a lot of them as well.
And, given that Qt switched in Qt 3 to the closest thing to a standard way of handling the PRIMARY and CLIPBOARD selections in X, and that a number of other toolkits, including GTK+, have always done that, it would probably work even between applications using different toolkits in most if not all cases.
I.e., bitching about copy-and-paste in X11 is getting a bit old, at least for complaints about it not working at all, even for text. Perhaps for non-text formats there needs to be a bit more work in the toolkits and applications, but, as I remember, the selections mechanism in the ICCCM does have a mechanism to register data types and to have a recipient of data find out the types in which data in a selection is available, so they can choose the "best" type (e.g., it might be available as rich text or plain text, so that a word processor would fetch the rich-text version but a terminal window would fetch the plain-text version).
Correct, although...
...that doesn't mean that suffixes aren't needed at all on UN*X - try calling a C source file "foo.f" and see how eager GCC, for example, is to compile it:
At the desktop GUI level, some UN*X desktops, such as KDE and, I think, Gnome (and possibly CDE and others) don't require suffixes in many cases, as they do file-style file type determination by looking at the file's contents, and give the file the right icon, launch the right application when you click the file, etc., but whether that behavior can be attributed to "Unix" is another matter. At least one UN*X desktop is mainly suffix-based and doesn't do that sort of "look at the file contents" file type determination, although I guess if the file's on a file system that supports resource forks and the resource fork has the right type and/or creator code it might work.
Umm, no, OS X definitely lets you add handlers for arbitrary URL schemes, and I infer from what others have said in replies to the original article that Windows does so as well. They don't have an IOSlave equivalent, but, at least in OS X, I'd be inclined to implement that as a user-mode NFS server, which means it'd be more general than an IOSlave, because it'd be usable by all applications, not just KDE applications (see, for example, OS X's mount_ftp, which I think might work through a user-mode FTP server with an FTP client as a back end). If possible, I'd be inclined to do it with a user-mode SMB server in Windows, although that might be less likely to work on port other than 139 or 445 (and thus less likely to run without interfering with any standard SMB server running on the machine).
But do they have the expertise to write a user-mode NFS server that uses the protocol in question as the back end? There'd still be some platform-dependent crap to do the NFS mount (probably using a port other than 2049, if the platform's NFS client supports that), and there might be some file systems where that doesn't work all that well, but it might work well for many of them.
Unfortunately, NFSv2 and v3 don't have "open" operations, so read/write file systems might be a little painful if the file system protocol is oriented towards copying entire files, as you'd probably want to implement writing by writing to a local copy of the file and writing the file back to the server when it's closed. NFSv4 might help, although that'd help only on OSes with NFSv4 clients mature enough for that purpose (Linux's might be; I think Solaris 10 will have a v4 client which might be; there are v4 clients under development for the BSDs, although I don't know whether they'll end up in OS X at some point).
For access to tarballs, zipballs, and the like, read/write access would be tricky, as you easily can't update individual files in place. If you offer read-only access, a user-mode NFS server would probably work.
I.e., something such as this OS X problem?
Yup. (Are smb: URLs in Konqueror, on OSes with an SMB client VFS, handled by a userland SMB client IOSlave, or handled by mounting the file system and accessing it through standard UN*X APIs?)
One problem with doing it in the VFS layer, though, is that you might need to stuff a VFS into the kernel. For some protocols, you might be able to use a user-mode NFS server (which is sort of the "standard" way to do a user-mode file system in most UN*Xes) instead; I don't know whether all of the "remote file access over protocols not really intended for use as remote file access protocols" file systems could be made to work that way or not. If not, it might be nice if there were some other hook into which user-mode daemons to support those protocols could be plugged, so that a kernel-mode VFS stub to talk to the daemon doesn't have to be written.
U2 are still around, Led Zep aren't.
I'll take a The Stalin iPod.
You misspelled "nucular".
...complete with an FTP client:
Or maybe that's two "cubes" links - one for the OS X Setup Assistant (if you can find a link for that), which, at least on machines with enough graphics horsepower, uses a rotating cube effect, and Keynote, where a rotating cube is at least one of the transition effects you can use.
How about ice hockey? (I though I'd remembered hearing that Torvalds had suggested that Tux and Beastie play ice hockey with Bill Gates' head, but either that happened in another message or didn't happen at all.)
The difference here is that Linux never attempted to be compatible with any of the Apple II OSes, but it does attempt to be a UN*X-compatible OS.
"Not being constrained by legacy APIs" in the sense that it can cheerfully break compatibility with them (a claim for which I've seen little, if any, evidence - yeah, perhaps that sort of breakage occurs on occasion, but that arguably makes it no different from other UN*Xes), "not being constrained by legacy APIs" in the sense that it can introduce new APIs for new capabilities (which makes it no different from other UN*Xes), or "not being constrained by legacy APIs" in the sense that it can introduce new APIs to supplant legacy APIs (and even that arguably makes it no different from other UN*Xes)?
At least partially, given that Darwin includes WebKit.
So are you saying Solaris isn't a mainframe OS, or GNOME doesn't offer advanced graphical capaiblities? (NOTE: I'm not arguing here either that Solaris is a mainframe OS or that GNOME does offer advanced graphical capabilities. I leave it to you to make arguments for or against those propositions.)
There's more to Darwin (the WWDC Developer Preview release of 8.0b1, in particular) than xnu. There's also, for example, WebCore. (Those links might require APSL registration.)