Anyway, OSX uses the Mach kernel, which is based on BSD
No, it's based on Mach.
and it runs some sort of BSD compatibility layer (though I'm not sure what that entails)
It entails kernel code implementing a set of BSD-flavored UN*X system calls, using Mach kernel primitives for process management, VM management, and the like, as per the Darwin kernel architecture page.
Much of the BSD-layer code comes from various versions of BSD, perhaps modified to fit the architecture of Darwin rather than the BSD whence it came.
I.e.,/mach_kernel includes both the (non-BSD-derived) Mach kernel and a bunch of (BSD-derived, to a large degree) code that runs atop the kernel and provides the standard system call interface. (Other kernel-mode code is in "kernel extensions", i.e. loadable kernel modules.)
BSD is UNIX. Not only that, it's one of the first UNIX certified operating systems.
I don't see BSD mentioned anywhere on the list of certified products - do you have any information on some older version of the standard, e.g. UNIX 95, for which "BSD" is certified?
I can't tell you a great deal about the early days of UNIX, but University of California at Berkeley's computer science department did a lot of work with Bell Labs to create the original UNIX.
That's not exactly how "the early days of UNIX" went. The original UNIX came from Bell Labs; people at a number of universities, research institutions, etc. had their own sets of improvements to UNIX that they distributed to other licensees. The Berkeley Software Distribution was one of them; the Fourth Berkeley Software Distribution was arguably one of the most important, if not the most important, of those, and with 4.2BSD the Berkeley contribution was arguably as important as the contemporary AT&T contributions.
But the "original UNIX" wasn't a joint effort of AT&T and UCB, although just about any modern UNIX has a significant number of BSD contributions (sockets, symlinks, etc.), whether the code came from Berkeley or was a reimplementation of stuff from Berkeley.
UNIX is a certification and registered trademark, not a single operating system.
Yes, that's what it is now, at least at the legal level, as per The Open Group's What is UNIX ®. Sometimes "UN*X" is used to refer not only to those OSes certified as "UNIX®", but to those OSes that haven't gone through the registration procedure but that are generally thought of as enough like other OSes considered "UNIX" to be worthy of the name. (I'd definitely put the major Linux distribution into the "UN*X" category, along with {Free,Net,Open,Dragonfly}BSD and OS X.)
CLI is a bridge that Apple will burn along the path to acceptance and marketshare. netstat, chown, rm, nidump, etc... go away for users.
Most users probably don't even know that stuff exists. (Terminal is in the Utilities subdirectory of/Applications, and at least some of the commands might be installed only if you install the BSD subsystem.) I have no reason to believe that they'll go away any time soon.
Now, as far as having some tcsh commandline skills on OSX, that would surely be useful for some every-day puttering around on the desktop.
Or for doing software development; I do that in a Terminal window. (At some point I need to do a little GUI stuff and see what I can find if I throw Ethereal to the Shark, though.:-))
But most anyone I know (primarily solaris, Linux, Freebsd and Obsd guys) who ran out and bought a powerbook or such for OSX either now dual boot or have wiped OSX completely for *BSD or *nuxPPC.
Well, I'm a UN*X guy (mainly Solaris at work at my previous job, mainly FreeBSD at home prior to getting the PowerBook, with Linux and assorted others thrown in as well) who has a PowerBook and I now run, err, umm, OS X on it. It's UN*X enough for me (and it comes with GNU make, rather than BSD make - perhaps that's a NeXTStEP-ism, as I think NeXTStEP might have antedated BSD make; development using automake/autoconf doesn't work well with BSD make).
...since the first thing one learns about OSX is that it makes traditional "find" incantations completely malfunction due to filenames with spaces in them
I can't remember whether I first had to use -print0 on OS X or on FreeBSD.
(Of course, OS X has more files with blanks that are its fault rather than the user's fault; I forget whether KDE on FreeBSD created any files under my home directory with blanks of its own volition, but OS X sure as heck does, e.g. under ~/Library.)
But people who do find | xargs arguably should use -print0 and -0, if available, anyway, just in case somebody planted a file with a newline in the name just for fun, for example.
See *most* of us "Unix guys" really don't even use a gui.
And some of us "Unix guys" (since 1977 or so, in my case) use GUIs for some things and CLIs for others. For my collections of various documents (network standards documents, for example), I use the KDE and OS X GUIs - it's easier to browse through and find the document I want rather than wasting an xterm/Konsole/Terminal window that could be better put to other purposes.
On the other hand, my OS X desktop is often cluttered enough with windows obscuring the desktop that it's easier to open a document by pushd-ing to ~/Desktop, running open on the file in question, and popd-ing back to whatever I was doing. (If I already know what the file name is, or if I know what it begins with so I can find it with file name completion, the terminal window is in use for a sufficiently short period of time that the problem mentioned in the previous paragraph is a small problem.)
So the answer, much though it might peeve those with a particular ideology (regardless of whether the ideology is "CLI bad, GUI good" or "GUI bad, CLI good"), is "it depends".
And by your logic, printing something in their publication isn't the same as them actually believing it will happen.
By "will happen" do you mean "should happen"?
And who is the "they" to whom you're referring? The editorial board of {The Guardian,National Review}? The owners/publishers of {The Guardian,National Review}? In either case, I suspect that, by his logic, the fact that an article that appears to advocate X is printed in a publication is, indeed, not the same as the editorial board, or owners, believing X should happen. Good grief, the November 8th issue of The Nation had an article by David Corn "Why I'm for Kerry" and an article by Christopher Hitchens "Why I'm (Slightly) for Bush" - by any logic that proceeds from "an article advocating X is printed in a publication" to "the {owners,editorial board} of that publication believe X should happen", The Nation believed both Kerry and Bush should be elected.
B: Mac OS X seems to insist you do everything in a GUI,
What sort of "everything" are you thinking of here? I certainly don't do my compiles in a GUI - and, heck, I even move stuff to and from the desktop using mv from a Terminal window.
E: The keyboard combinations are horrible. I realize that there's no standard with keyboard buttons, but Mac doesn't even try. In fact, it goes out of its way to change everything. Use a Mac for a week, and you get used to Alt+Z/X/C/V, go back to Windows / Unix, and you're screwing up your copy / paste.
Apple didn't change anything - Command+Z/C/X/V existed (Command, not Alt), as far as I know, before Ctrl+Z/X/C/V; I think it dates back to the original Mac (although it might've been called Apple rather than Command). Microsoft may have changed it, as PC's didn't have an Apple or Command key, and they had other uses for the Alt key.
F: The system has inherently stupid design ideas. Examples include: Maximizing a window only maximizes it vertically, you get to drag it to fully maximize it. You can only drag the bottom right corner, which is often covered by the dock with the default settings.
I certainly don't care for that OS X behavior; I don't know whether there's a rationale for it or not.
Another example is when you close applications. You would think the X would mean 'Close', right? Nope. You have to right click (again, I kid) the button on the taskbar and click close after closing the application first.
Actually, the X does mean "Close", as in "Close the window" - the Windows desktop, and many UN*X+X11 window managers, also implement a window button (often with an "X") whose effect is to close the window. You're probably getting bitten by the fact that closing the last window in an application doesn't cause the application to exit (unlike what usually happens on Windows and UN*X+X11) - and that opening a new document with an application doesn't cause a new process to be created if there's already a process running that application, it just causes that process to be told to open the new document. No, I don't know why that's the convention, and it makes it a bit more of a pain to write applications, as they have to support multiple documents, and thus might not be able to keep global information about the document, as they could if each document has a separate process.
And yet another stupid move is the way the menu bars for each app is only displayed at the top.
The argument in favor of it is that it's easier to move the mouse cursor to the menu bar, as you don't have to aim for an arbitrary vertical position on the screen - but you still have to get the horizontal position right.
What if you minimize Firefox and click on your desktop? The only way to get a new window open is to click on firefox in the dock (the actual application icon that normally launches it initially, but in this case it would remain open), then go through the menu to create a new window.
...or moving the mouse over the Dock icon for the application and using Command+N.
At least some of the UI design decisions to which you're objecting might be holdovers from pre-OS X Mac OS, dating back to the original version of the OS, which had no multitasking. That might be a reason for the single menu bar; I don't know whether the "one process for all documents" idea comes from classic Mac OS or from NeXTStEP, however.
B: Mac OS X seems to insist you do everything in a GUI,
What sort of "everything" are you thinking of here? I certainly don't do my compiles in a GUI - and, heck, I even move stuff to and from the desktop using mv> from a Terminal window.
E: The keyboard combinations are horrible. I realize that there's no standard with keyboard buttons, but Mac doesn't even try. In fact, it goes out of its way to change everything. Use a Mac for a week, and you get used to Alt+Z/X/C/V, go back to Windows / Unix, and you're screwing up your copy / paste.
Apple didn't change anything - Command+Z/C/X/V existed (Command, not Alt), as far as I know, before Ctrl+Z/X/C/V; I think it dates back to the original Mac (although it might've been called Apple rather than Command). Microsoft may have changed it, as PC's didn't have an Apple or Command key, and they had other uses for the Alt key.
F: The system has inherently stupid design ideas. Examples include: Maximizing a window only maximizes it vertically, you get to drag it to fully maximize it. You can only drag the bottom right corner, which is often covered by the dock with the default settings.
I certainly don't care for that; I don't know whether there's a rationale for it or not.
Another example is when you close applications. You would think the X would mean 'Close', right? Nope. You have to right click (again, I kid) the button on the taskbar and click close after closing the application first.
Actually, the X does mean "Close", as in "Close the window" - the Windows desktop, and many UN*X+X11 window managers, also implement a window button (often with an "X") whose effect is to close the window. You're probably getting bitten by the fact that closing the last window in an application doesn't cause the application to exit (unlike what usually happens on Windows and UN*X+X11) - and that opening a new document with an application doesn't cause a new process to be created if there's already a process running that application, it just causes that process to be told to open the new document. No, I don't know why that's the convention, and it makes it a bit more of a pain to write applications, as they have to support multiple documents, and thus might not be able to keep global information about the document, as they could if each document has a separate process.
And yet another stupid move is the way the menu bars for each app is only displayed at the top.
The argument in favor of it is that it's easier to move the mouse cursor to the menu bar, as you don't have to aim for an arbitrary vertical position on the screen - but you still have to get the horizontal position right.
What if you minimize Firefox and click on your desktop? The only way to get a new window open is to click on firefox in the dock (the actual application icon that normally launches it initially, but in this case it would remain open), then go through the menu to create a new window.
...or moving the mouse over the Dock icon for the application and using Command+N.
At least some of the UI design decisions to which you're objecting might be holdovers from pre-OS X Mac OS, dating back to the original version of the OS, which had no multitasking. That might be a reason for the single menu bar; I don't know whether the "one process for all documents" idea comes from classic Mac OS or from NeXTStEP, however.
In Linux, if you want to wait on file descriptors and signals at the same time without a race condition, your only option involves longjmp()ing out of signal handlers.::shudder::
Yup, longjmp()ing out of signal handlers sucks. We finally gave up on SIGALRM+longjmp() as a timeout mechanism for IP address to host name lookups in Ethereal, because, in additiona to not being able to use it on Windows (which is where the timeout problem is worst, thanks to inverse NetBIOS-over-TCP lookups), we also can't use it in OS X (because you can longjmp() out of the middle of a send of a Mach message to lookupd, leaving the code to talk to lookupd in an inconsistent state, causing the next lookup attempt to crash) and in at least some versions of some Linux distributions (because gethostbyaddr(), at least with some versions of glibc, appears to grab a mutex that doesn't get released if you longjmp() out of it, so the next call hangs forever trying to grab the mutex).
This is why Darwin 7.x has all the cool features that the FreeBSD 5.x kernel has but most other unixes lack, like...
jails?
a devfs that lets you specify, via a configuration file, what permissions are to be given to newly-created devices?
netgraph?
an NFSv4 client? (Well, OK, Linux already has that, and I think Solaris 10 will have it as well, so not as many UN*Xes lack it.)
You might or might not consider those "cool features", but they're features in FreeBSD 5.x that are not in Darwin. There are probably other FreeBSD kernel features not in Darwin - and Darwin features not in FreeBSD.
Keep in mind that even though the core protocols haven't changed that much, actual TCP/IP deployments have drastically changed since the early 80s. Efficient packet forwarding algorithms (which are necessary in Gigabit networks and beyond) are certainly subject to patents today.
As might efficient packet discarding algorithms, as per their listing the Discard Protocol as one of the protocols you can license from them.
That strongly suggests to me, at least, that they just enumerated protocols Microsoft implements but didn't invent solely by themselves (or didn't invent at all), and threw them into the list, perhaps on the theory that it's better that other organizations and individuals spend time figuring out what stuff might be covered by patents owned by Microsoft than that they spend time figuring out what public protocols actually are covered, in part or in whole, by some Microsoft patent.
The wiki link provided showed AIX is a micro kernel design.
The Wiki link provided asserted that AIX is a microkernel design. That doesn't mean that it is a microkernel; whoever put that entry into the Wikipedia might just have been confused (e.g., thinking of the RT PC AIX, running atop the hypervisor, and thinking of the hypervisor as a microkernel).
AIX is not a pure micro based but something called an exokernel. I am not an expert on this but other slashdotters mentioned that exokernels are micro based but graphics are run in the kernel as well as a few other subtile differences.
I'm not sure those other Slasdotters are experts, either, as I've not seen "exokernel" used in the sense of "a small kernel to which user-mode servers are added to handle file systems, network protocols, and the like" - the sense in which I've usually seen "microkernel" used when it's describing something that's not a "modified microkernel" along the lines of NT's kernel or Darwin's xnu; it generally seems to refer to a kernel that provides very low-level primitives that provide a secure interface to the low-level hardware, with file systems, network protocols, and the likes implemented as libraries that use those low-level primitives. See the MIT Exokernel Operating System page, for example, or the Wikipedia article on "kernels" in the OS sense.
I've certainly not seen anything about an exokernel being like a microkernel except that graphics are run in the kernel; that sounds more like a "modified microkernel" to me.
But really it is a microkernel like design
Really? To which version of AIX are they referring? The current one for RS/6000s (and post-Great Renaming POWER series IntelliStations and p5 and pSeries servers), in its Kernel Extensions and Device Support Programming Concepts manual, speaks of a fairly traditional VFS interface (suggesting that file systems run in kernel mode, not in userland), speaks of "network kernel services" that at least suggest that network protocols run in kernel mode, and speaks of subsystems for various driver types suggesting that those drivers run in kernel mode as well.
IBM's had several different OSes named "AIX" that were not, as far as I know, the same OS. One of them - the one for the RT PC, I think - did, if I remember correctly what I'd read, have a "hypervisor" atop which the OS kernel ran, but I don't think the kernel in question ran in user mode atop the hypervisor, and that's not the flavor of AIX running on RS/6000's and POWER series IntelliStations/p5 and pSeries servers.
What kills me is he using Linux and not Darwin, AIX, or MacOSX which are "not obsolete".
I was unaware that AIX was considered microkernel-based. As for Darwin, whilst there is Mach in it, file systems, network protocols, and drivers for many devices (disk controllers, network adapters) don't operate as Mach servers, they're in the kernel (except for file systems such as webdavfs that hand a lot of work to a user-mode daemon, but it's a bit of an exception).
And this is apropos of what? To what other post are you referring? I'm not sure how that relates to "Except that it's not news for me" - it's not as if you should only be expected not to assume I was unfamiliar with KIO only if you'd read some other post in which I explicitly mentioned them.
your discussion of EOPNOTSUPP does not follow
It follows from the remarks about record locking, given that you'll get that error if you try locking on a file system that doesn't support it (such as an NFS file system mounted with the "don't do record locking" option).
you would get EROFS, no?
No. You'd get EOPNOTSUPP if you try to do record locking. You'd get EROFS if you tried to, for example, open for writing, if the FTP file system is read-only, but the fact that it's read-only is a consequence of the implementation, not an inherent characteristic of FTP-based file systems.
so I'm confused why you even brought it up.
Brought what up? EOPNOTSUPP? I brought it up as an answer to at least part of your question "How would KDE handle a (for example) 10MB MDB database file that uses file record locking?", explaining how that'd be handled by OS X (i.e., it's not handled by "not having [this] feature").
Hopefully your knee didn't jerk just because you saw "...OS X do not have these features..."
Well, OS X doesn't have the exact same feature, but it does have UNIX file-system API access to file systems mounted over FTP, so it was a response to "Windows and OS X do not have these features" that noted that OS X does have a similar feature, so "that feature is bogus - see, OS X doesn't have it because it can't handle a database file" is not a valid response to "this feature is cool", because it's not a true assertion.
BTW, at least from the KIO documentation I've seen, KIO is oriented towards sequential reading and writing of an entire file; if so, it wouldn't handle a shared database file at all. That doesn't render the feature completely useless.
page fault handling should be able to use user-mode code or
you should not be allowed to mmap() files or do demand-paged execution on remote file systems.
For example, NFS used to assume that both the kernel and the network could be trusted (it's gotten a bit better since, but its hard to change it completely).
Unless by "trusted" you're referring to not getting packets-of-death sent to you (causing kernel buffer overflows and the like), that's not an obvious reason why it shouldn't be in the kernel. If you're referring to trusting credentials, that'd be an issue regardless of whether the NFS client (or server) is running in user mode or kernel mode.
Or take NFS: it has to have special hacks to disable some file system functionality (e.g., setuid) because remote file systems can't be trusted.
That's not an NFS-specific issue - it's an issue for all "removable media" in the sense of "media not necessarily produced solely by this machine".
And think of the messes it creates in the kernel: the kernel now needs to know about key management, cryptography, remote user id mappings, new failure modes on file accesses, and lots of other stuff.
The cryptography and key management can be handled in user-mode helper daemons (unless, by the reference to "VFS hooks", you're considering those user-mode helper daemons to be, in effect, parts of the kernel). I'm not sure why the new failure modes are a huge problem - ETIMEDOUT isn't that much different from EIO.
For example, "cd ftp://ftp.foo.org/pub" should automatically mount the ftp server appropriately.
...although it'd change pathname semantics in an incompatible fashion; perhaps it's unlikely that the current directory has a directory in it named "ftp:", but:
$ cd ftp://ftp.foo.org/pub $ ls hello
but those are all just ordinary files.
If you're willing to put up with a syntax other than URL syntax,/ftp/ftp.foo.org/pub could be done, with the right type of file system mounted on/ftp - and/http, and so on.
Or perhaps violating POSIX semantics in this case would be unlikely enough to cause real-world problems that you could get away with it - or would be "optional" in the sense that only if a particular bit of kernel code (probably acting as a gateway to a user-mode FTP/HTTP/etc. client that dos all the heavy lifting) was enabled or "mounted" would the pathname parser special case {ftp,http,...}://.
Isn't it easier to make foo.tar.gz both a file and a directory, and mount the new filesystem there?
Yes (although, as you note, it'd probably be done a little differently with metadata-as-files - an idea I've seen suggested elsewhere as well).
I don't believe that any remote file system should go through kernel system calls; that raises security concerns that simply need not be raised in the first place, and it has unnecessary performance costs.
I.e., the kernel NFS client implementations in (SunOS,Digital UNIX, AIX, HP-UX, Linux, FreeBSD, NetBSD, OpenBSD, OS X, etc., etc., etc.} should be removed, as should smbfs in {Linux, FreeBSD, NetBSD, OS X} and cifsfs in Linux, as well as nwfs in {Linux, whatever BSDs have it} and afs in {OS X, Linux and/or BSDs if they have it}? (I'm not saying that shouldn't be done, but that is a consequence of saying that you "don't believe that any remote file system should go through kernel system calls".)
NFS wasn't designed for this sort of thing, so even if one believes that the right way of implementing FTP and WebDAV file systems is with a kernel stub and a user mode server, using NFS just can't be the right choice.
I didn't say it was the right choice (for example, unless you're using NFSv4, you don't get open and close notifications, making it harder to implement a read/write file system if the protocol being used only supports whole-file updates - you don't know when a file has been completely written out and thus ready to be pushed back), but it is a choice that avoids making any kernel changes, if, for whatever reason, you want to or have to avoid doing so.
If you mean the kernel VFS layer, then Apple is not doing it right: this sort of functionality does not belong in the kernel.
The only part that's in the kernel for FTP is the NFS client (which is useful for more than talking to a user-mode NFS server/FTP client program) and a small "stub" file system for WebDAV that talks to a user-mode WebDAV client.
Slashdot Mirror
The Carbon-based Finder seems to hande them OK; is the problem that Word is Carbon-based, or does the fault lie elsewhere?
I like Cocoa apps because a number of Emacs keystrokes work in them, at least in Panther (^A, ^E, ^N, ^P, ^B, ^F, ^K, for example).
No, it's based on Mach.
It entails kernel code implementing a set of BSD-flavored UN*X system calls, using Mach kernel primitives for process management, VM management, and the like, as per the Darwin kernel architecture page.
Much of the BSD-layer code comes from various versions of BSD, perhaps modified to fit the architecture of Darwin rather than the BSD whence it came.
I.e., /mach_kernel includes both the (non-BSD-derived) Mach kernel and a bunch of (BSD-derived, to a large degree) code that runs atop the kernel and provides the standard system call interface. (Other kernel-mode code is in "kernel extensions", i.e. loadable kernel modules.)
I don't see BSD mentioned anywhere on the list of certified products - do you have any information on some older version of the standard, e.g. UNIX 95, for which "BSD" is certified?
That's not exactly how "the early days of UNIX" went. The original UNIX came from Bell Labs; people at a number of universities, research institutions, etc. had their own sets of improvements to UNIX that they distributed to other licensees. The Berkeley Software Distribution was one of them; the Fourth Berkeley Software Distribution was arguably one of the most important, if not the most important, of those, and with 4.2BSD the Berkeley contribution was arguably as important as the contemporary AT&T contributions.
But the "original UNIX" wasn't a joint effort of AT&T and UCB, although just about any modern UNIX has a significant number of BSD contributions (sockets, symlinks, etc.), whether the code came from Berkeley or was a reimplementation of stuff from Berkeley.
Yes, that's what it is now, at least at the legal level, as per The Open Group's What is UNIX ®. Sometimes "UN*X" is used to refer not only to those OSes certified as "UNIX®", but to those OSes that haven't gone through the registration procedure but that are generally thought of as enough like other OSes considered "UNIX" to be worthy of the name. (I'd definitely put the major Linux distribution into the "UN*X" category, along with {Free,Net,Open,Dragonfly}BSD and OS X.)
Most users probably don't even know that stuff exists. (Terminal is in the Utilities subdirectory of /Applications, and at least some of the commands might be installed only if you install the BSD subsystem.) I have no reason to believe that they'll go away any time soon.
XML? I'd post a link to the LINUXML project, but it appears that the pages for it have gone away; here's a copy of some LINUXML stuff.
I'd have done it in Windows with
but that's because I have Cygwin installed in the Windows partition on the machine I have with Windows.
Or for doing software development; I do that in a Terminal window. (At some point I need to do a little GUI stuff and see what I can find if I throw Ethereal to the Shark, though. :-))
Well, I'm a UN*X guy (mainly Solaris at work at my previous job, mainly FreeBSD at home prior to getting the PowerBook, with Linux and assorted others thrown in as well) who has a PowerBook and I now run, err, umm, OS X on it. It's UN*X enough for me (and it comes with GNU make, rather than BSD make - perhaps that's a NeXTStEP-ism, as I think NeXTStEP might have antedated BSD make; development using automake/autoconf doesn't work well with BSD make).
I can't remember whether I first had to use -print0 on OS X or on FreeBSD.
(Of course, OS X has more files with blanks that are its fault rather than the user's fault; I forget whether KDE on FreeBSD created any files under my home directory with blanks of its own volition, but OS X sure as heck does, e.g. under ~/Library.)
But people who do find | xargs arguably should use -print0 and -0, if available, anyway, just in case somebody planted a file with a newline in the name just for fun, for example.
And some of us "Unix guys" (since 1977 or so, in my case) use GUIs for some things and CLIs for others. For my collections of various documents (network standards documents, for example), I use the KDE and OS X GUIs - it's easier to browse through and find the document I want rather than wasting an xterm/Konsole/Terminal window that could be better put to other purposes.
On the other hand, my OS X desktop is often cluttered enough with windows obscuring the desktop that it's easier to open a document by pushd-ing to ~/Desktop, running open on the file in question, and popd-ing back to whatever I was doing. (If I already know what the file name is, or if I know what it begins with so I can find it with file name completion, the terminal window is in use for a sufficiently short period of time that the problem mentioned in the previous paragraph is a small problem.)
So the answer, much though it might peeve those with a particular ideology (regardless of whether the ideology is "CLI bad, GUI good" or "GUI bad, CLI good"), is "it depends".
By "will happen" do you mean "should happen"?
And who is the "they" to whom you're referring? The editorial board of {The Guardian,National Review}? The owners/publishers of {The Guardian,National Review}? In either case, I suspect that, by his logic, the fact that an article that appears to advocate X is printed in a publication is, indeed, not the same as the editorial board, or owners, believing X should happen. Good grief, the November 8th issue of The Nation had an article by David Corn "Why I'm for Kerry" and an article by Christopher Hitchens "Why I'm (Slightly) for Bush" - by any logic that proceeds from "an article advocating X is printed in a publication" to "the {owners,editorial board} of that publication believe X should happen", The Nation believed both Kerry and Bush should be elected.
Yes, I know, I didn't close the <tt>. Try:
What sort of "everything" are you thinking of here? I certainly don't do my compiles in a GUI - and, heck, I even move stuff to and from the desktop using mv from a Terminal window.
Apple didn't change anything - Command+Z/C/X/V existed (Command, not Alt), as far as I know, before Ctrl+Z/X/C/V; I think it dates back to the original Mac (although it might've been called Apple rather than Command). Microsoft may have changed it, as PC's didn't have an Apple or Command key, and they had other uses for the Alt key.
I certainly don't care for that OS X behavior; I don't know whether there's a rationale for it or not.
Actually, the X does mean "Close", as in "Close the window" - the Windows desktop, and many UN*X+X11 window managers, also implement a window button (often with an "X") whose effect is to close the window. You're probably getting bitten by the fact that closing the last window in an application doesn't cause the application to exit (unlike what usually happens on Windows and UN*X+X11) - and that opening a new document with an application doesn't cause a new process to be created if there's already a process running that application, it just causes that process to be told to open the new document. No, I don't know why that's the convention, and it makes it a bit more of a pain to write applications, as they have to support multiple documents, and thus might not be able to keep global information about the document, as they could if each document has a separate process.
The argument in favor of it is that it's easier to move the mouse cursor to the menu bar, as you don't have to aim for an arbitrary vertical position on the screen - but you still have to get the horizontal position right.
...or moving the mouse over the Dock icon for the application and using Command+N.
At least some of the UI design decisions to which you're objecting might be holdovers from pre-OS X Mac OS, dating back to the original version of the OS, which had no multitasking. That might be a reason for the single menu bar; I don't know whether the "one process for all documents" idea comes from classic Mac OS or from NeXTStEP, however.
What sort of "everything" are you thinking of here? I certainly don't do my compiles in a GUI - and, heck, I even move stuff to and from the desktop using mv> from a Terminal window.
Apple didn't change anything - Command+Z/C/X/V existed (Command, not Alt), as far as I know, before Ctrl+Z/X/C/V; I think it dates back to the original Mac (although it might've been called Apple rather than Command). Microsoft may have changed it, as PC's didn't have an Apple or Command key, and they had other uses for the Alt key.
I certainly don't care for that; I don't know whether there's a rationale for it or not.
Actually, the X does mean "Close", as in "Close the window" - the Windows desktop, and many UN*X+X11 window managers, also implement a window button (often with an "X") whose effect is to close the window. You're probably getting bitten by the fact that closing the last window in an application doesn't cause the application to exit (unlike what usually happens on Windows and UN*X+X11) - and that opening a new document with an application doesn't cause a new process to be created if there's already a process running that application, it just causes that process to be told to open the new document. No, I don't know why that's the convention, and it makes it a bit more of a pain to write applications, as they have to support multiple documents, and thus might not be able to keep global information about the document, as they could if each document has a separate process.
The argument in favor of it is that it's easier to move the mouse cursor to the menu bar, as you don't have to aim for an arbitrary vertical position on the screen - but you still have to get the horizontal position right.
...or moving the mouse over the Dock icon for the application and using Command+N.
At least some of the UI design decisions to which you're objecting might be holdovers from pre-OS X Mac OS, dating back to the original version of the OS, which had no multitasking. That might be a reason for the single menu bar; I don't know whether the "one process for all documents" idea comes from classic Mac OS or from NeXTStEP, however.
s/With enough thrust/With enough upward thrust/
Yup, longjmp()ing out of signal handlers sucks. We finally gave up on SIGALRM+longjmp() as a timeout mechanism for IP address to host name lookups in Ethereal, because, in additiona to not being able to use it on Windows (which is where the timeout problem is worst, thanks to inverse NetBIOS-over-TCP lookups), we also can't use it in OS X (because you can longjmp() out of the middle of a send of a Mach message to lookupd, leaving the code to talk to lookupd in an inconsistent state, causing the next lookup attempt to crash) and in at least some versions of some Linux distributions (because gethostbyaddr(), at least with some versions of glibc, appears to grab a mutex that doesn't get released if you longjmp() out of it, so the next call hangs forever trying to grab the mutex).
You might or might not consider those "cool features", but they're features in FreeBSD 5.x that are not in Darwin. There are probably other FreeBSD kernel features not in Darwin - and Darwin features not in FreeBSD.
As might efficient packet discarding algorithms, as per their listing the Discard Protocol as one of the protocols you can license from them.
That strongly suggests to me, at least, that they just enumerated protocols Microsoft implements but didn't invent solely by themselves (or didn't invent at all), and threw them into the list, perhaps on the theory that it's better that other organizations and individuals spend time figuring out what stuff might be covered by patents owned by Microsoft than that they spend time figuring out what public protocols actually are covered, in part or in whole, by some Microsoft patent.
The Wiki link provided asserted that AIX is a microkernel design. That doesn't mean that it is a microkernel; whoever put that entry into the Wikipedia might just have been confused (e.g., thinking of the RT PC AIX, running atop the hypervisor, and thinking of the hypervisor as a microkernel).
I'm not sure those other Slasdotters are experts, either, as I've not seen "exokernel" used in the sense of "a small kernel to which user-mode servers are added to handle file systems, network protocols, and the like" - the sense in which I've usually seen "microkernel" used when it's describing something that's not a "modified microkernel" along the lines of NT's kernel or Darwin's xnu; it generally seems to refer to a kernel that provides very low-level primitives that provide a secure interface to the low-level hardware, with file systems, network protocols, and the likes implemented as libraries that use those low-level primitives. See the MIT Exokernel Operating System page, for example, or the Wikipedia article on "kernels" in the OS sense.
I've certainly not seen anything about an exokernel being like a microkernel except that graphics are run in the kernel; that sounds more like a "modified microkernel" to me.
Really? To which version of AIX are they referring? The current one for RS/6000s (and post-Great Renaming POWER series IntelliStations and p5 and pSeries servers), in its Kernel Extensions and Device Support Programming Concepts manual, speaks of a fairly traditional VFS interface (suggesting that file systems run in kernel mode, not in userland), speaks of "network kernel services" that at least suggest that network protocols run in kernel mode, and speaks of subsystems for various driver types suggesting that those drivers run in kernel mode as well.
IBM's had several different OSes named "AIX" that were not, as far as I know, the same OS. One of them - the one for the RT PC, I think - did, if I remember correctly what I'd read, have a "hypervisor" atop which the OS kernel ran, but I don't think the kernel in question ran in user mode atop the hypervisor, and that's not the flavor of AIX running on RS/6000's and POWER series IntelliStations/p5 and pSeries servers.
I was unaware that AIX was considered microkernel-based. As for Darwin, whilst there is Mach in it, file systems, network protocols, and drivers for many devices (disk controllers, network adapters) don't operate as Mach servers, they're in the kernel (except for file systems such as webdavfs that hand a lot of work to a user-mode daemon, but it's a bit of an exception).
And this is apropos of what? To what other post are you referring? I'm not sure how that relates to "Except that it's not news for me" - it's not as if you should only be expected not to assume I was unfamiliar with KIO only if you'd read some other post in which I explicitly mentioned them.
It follows from the remarks about record locking, given that you'll get that error if you try locking on a file system that doesn't support it (such as an NFS file system mounted with the "don't do record locking" option).
No. You'd get EOPNOTSUPP if you try to do record locking. You'd get EROFS if you tried to, for example, open for writing, if the FTP file system is read-only, but the fact that it's read-only is a consequence of the implementation, not an inherent characteristic of FTP-based file systems.
Brought what up? EOPNOTSUPP? I brought it up as an answer to at least part of your question "How would KDE handle a (for example) 10MB MDB database file that uses file record locking?", explaining how that'd be handled by OS X (i.e., it's not handled by "not having [this] feature").
Well, OS X doesn't have the exact same feature, but it does have UNIX file-system API access to file systems mounted over FTP, so it was a response to "Windows and OS X do not have these features" that noted that OS X does have a similar feature, so "that feature is bogus - see, OS X doesn't have it because it can't handle a database file" is not a valid response to "this feature is cool", because it's not a true assertion.
BTW, at least from the KIO documentation I've seen, KIO is oriented towards sequential reading and writing of an entire file; if so, it wouldn't handle a shared database file at all. That doesn't render the feature completely useless.
So you're also saying either that
Unless by "trusted" you're referring to not getting packets-of-death sent to you (causing kernel buffer overflows and the like), that's not an obvious reason why it shouldn't be in the kernel. If you're referring to trusting credentials, that'd be an issue regardless of whether the NFS client (or server) is running in user mode or kernel mode.
That's not an NFS-specific issue - it's an issue for all "removable media" in the sense of "media not necessarily produced solely by this machine".
The cryptography and key management can be handled in user-mode helper daemons (unless, by the reference to "VFS hooks", you're considering those user-mode helper daemons to be, in effect, parts of the kernel). I'm not sure why the new failure modes are a huge problem - ETIMEDOUT isn't that much different from EIO.
...although it'd change pathname semantics in an incompatible fashion; perhaps it's unlikely that the current directory has a directory in it named "ftp:", but:
but those are all just ordinary files.
If you're willing to put up with a syntax other than URL syntax, /ftp/ftp.foo.org/pub could be done, with the right type of file system mounted on /ftp - and /http, and so on.
Or perhaps violating POSIX semantics in this case would be unlikely enough to cause real-world problems that you could get away with it - or would be "optional" in the sense that only if a particular bit of kernel code (probably acting as a gateway to a user-mode FTP/HTTP/etc. client that dos all the heavy lifting) was enabled or "mounted" would the pathname parser special case {ftp,http,...}://.
Yes (although, as you note, it'd probably be done a little differently with metadata-as-files - an idea I've seen suggested elsewhere as well).
I.e., the kernel NFS client implementations in (SunOS,Digital UNIX, AIX, HP-UX, Linux, FreeBSD, NetBSD, OpenBSD, OS X, etc., etc., etc.} should be removed, as should smbfs in {Linux, FreeBSD, NetBSD, OS X} and cifsfs in Linux, as well as nwfs in {Linux, whatever BSDs have it} and afs in {OS X, Linux and/or BSDs if they have it}? (I'm not saying that shouldn't be done, but that is a consequence of saying that you "don't believe that any remote file system should go through kernel system calls".)
I didn't say it was the right choice (for example, unless you're using NFSv4, you don't get open and close notifications, making it harder to implement a read/write file system if the protocol being used only supports whole-file updates - you don't know when a file has been completely written out and thus ready to be pushed back), but it is a choice that avoids making any kernel changes, if, for whatever reason, you want to or have to avoid doing so.
The news for you is that it is the Finder feature - it does an FTP mount and then pops up a window for the top-level directory.
Except that it's not news for me, given that I also use KDE on my FreeBSD desktop (and was already aware of KIOSlaves).
The only part that's in the kernel for FTP is the NFS client (which is useful for more than talking to a user-mode NFS server/FTP client program) and a small "stub" file system for WebDAV that talks to a user-mode WebDAV client.