In other news, various pieces of hardware simultaneously vanished from the earth as, given that "RAID is dead" and that "Thunderbolt reigns supreme", it was logically impossible for a Thunderbolt-attached RAID device to exist.

And, presumably, can't do so in VMware Fusion or Parallels Workstation (which avoid the reboot and the "can't run your OS X apps and your Windows apps at the same time") or doesn't want to spend the money for them. (Yes, I can imagine that there are apps that don't work well enough in a simulated Windows box, for whatever reason.)

"Nice business you have there selling to defense/intelligence/etc. government customers. Shame if something happened to it...."

For forcible power-cycling, but if you're doing that a lot, you have bigger problems (or are doing development, especially kernel-mode code development).

(And if you want to power the machine down, rather than reboot, the "Shut Down..." menu option handles that.)

Correct for the iMac, as I remember; I'm not sure about the Mac mini, but I could easily believe it to be the case.

Some of the stuff above UNIX was significantly redone in Snow Leopard or Lion or both to provide new APIs that do fewer system calls to get file system information, and I think the Finder was changed to use that, so things may have improved somewhat.

There were also VFS-layer changes in Lion to allow system calls to make file system requests that bundle multiple operations into one, so that an open/create could be done in a single VFS-layer call, allowing a single over-the-wire call to be made.

The cited discussion stated with a post from somebody running Snow Leopard (10.6.1); I don't remember whether the stuff above UNIX was changed in Snow Leopard or not (yes, I know, Snow Leopard was mainly a performance release, but that doesn't mean no significant performance changes were made after that), but the VFS-layer changes were in Lion, so there could have been some improvements post-Snow Leopard.

Which says:

Finder is slow at listing the directory content of the shares The problem only occurs in Apple Finder. When I do "ls" from Terminal the directory listing displays in the same moment I hit enter.

so either the Finder is assuming some file system operations are always going to be fast when they're not fast over SMB, or smbfs needs to figure out how to make whatever the Finder's doing faster, or some combination of the two. I could certainly imagine the first of those being true (the stuff above UNIX has been known to implicitly assume that file system operations are cheap, when they might not be cheap for remote file systems).

And it behaves like it, modulo the sort of quirks that every UN\*X (whether it's UNIX(R) or not) has, and modulo a case-insensitive-by-default file system (which has only bitten me in a few cases, e.g. a CVS tree with source to CVS in it, so its CVS directory conflicted with the "cvs" source directory, and some renames of files in a remote SVN repository that only changed the case of the name).

If by "Economy" you mean "economics", you may well be mistaken. "I work in the analytical division of well-recognized company. Most of our vendors design instrumentation to work with Windows." sounds more like some form of laboratory science (biology or chemistry) than like economics. Do NOT become confused by the fact that they mentioned Reinhart-Rogoff; they also spoke of "Baggerly and Coombes" and "the Duke scandal", which was biomedicine, not economics.

The spin of charged particles gives them a magnetic moment (i.e., they have north and south magnetic poles). The spin of neutral particles, not so much.

Android's a bit more different from other Linux distributions than KDE-based distributions are from GNOME-based distributions.

All what come with gedit only? The KDE-based distributions probably don't come with gedit only.

You might not, but the user base as a whole might want it. At least some of the major desktop environments have their own text editors (Kate for KDE, gedit for GNOME), and may be set up so that's what you have by default; having extra ones doesn't cost much in terms of disk space (if it costs a lot in terms of brain stress at having to deal with having a choice, Linux probably really isn't for you - but, then, given both Notepad and Wordpad, Windows might not be for you, either).

The answer to the third question is "because there's hardware lockdown", i.e. Apple have chosen not to offer OS X for non-Apple machines and have chosen not to use AMD CPUs in their machines and, therefore, as they didn't need to support AMD CPUs in XNU, have chosen not to bother supporting them.

The answer to the first and second questions is "because, for whatever reason, Apple isn't interested in offering them" (combined with "because there's hardware lockdown", so you can't have machines like that from anybody else running OS X unless you make the machine a Hackintosh).

If that was deliberate, it gets the "funny post of the day" award.

If it was accidental, it gets the "funny typo of the day" award.

A knockoff that's competing with a family of OSes that aren't 100% compatible with each other at the source level, that run on machines that are typically more expensive than the primary class of machines on which the knockoffs run and that don't even have the same instruction sets as each other (so that binary compatibility is out of the question), and on which a lot of the software is either open-source or written in-house so that it can be compiled and run on the knockoff, could succeed.

A knockoff that's competing with a single OS that has a ~90% market share and that has a huge collection of binary-only packaged applications that might depend (explicitly or implicitly) not only on documented behavior but also on undocumented behavior is a different story.