9 times out of 10 when the public uses the word "theory" they really mean "hypothesis". Should that stop scientists from using the word "theory" correctly? Should that stop us from educating people about the real definition of the word "theory"? Should scientists have to change their language every time the public warps it beyond recognition?

"Correct" is a matter of context. I shouldn't expect that teenagers writing sms messages are going to eschew expediency for accuracy and as such excessive use of acronyms and false contractions can be considered "correct" in the context of an SMS. However that same message when included in a homework assignment can clearly be considered incorrect given the more formal context. Understanding and adjusting your language to suit the context and intended audience is something that is taught in the first week of nearly every first semester speech, writing and critical thinking course. To disregard these principal in favor of picking arguments based on some false premise is pedantic at best...

And before you jump in with some retort please consider for a moment the formal acceptance of the ideas I've expressed. In an America criminal court an expert recognized by the court is expected to use language that is specific to their expertise in a manner that is both consistent and correct within their claimed/recognized expertise. The same level of expectation is not levied upon an layperson when they are presented as a witness. Such that a layperson could and should be expected to say "theory" when they might actually mean "hypothesis" yet a scientist would be expected to both understand the difference and use the term which is correct within the domain of their meaning.

i wasn't trying to guess at what he needed, but his question was about snap shotting. One of (if not THE) key feature of a snapshot is that it is atomic. Anything that rolls through a changing filesystem one file at a time is not going to fit that bill. Also you run the risk of making "backups" that could break things that presume state consistency. If you capture the log of a daemon before the product output then your backup could have no record of the event which created the output for example.

These types of concerns are of increasing importance to professional system administrators in a time where there (to me at least) seems to be an increasing focus on meeting legally mandated audit and retention requirements.

This is no good for a true snapshot since the rsync operation is non-atomic on a live filesystem.

Yeah that title was referring to the swing axle rear suspension of the corvair.

While I basically agree with the premise of what you are saying, doesn't the SLI bus provide for having a shared memory segment between all the cards? I'm not 100% sure that is a feature of that specific interconnect; but I've always assumed it was. The difference being that if n cards with x memory would have a single (n*x) memory pool local to the processors plus the overhead of whatever locking semantics that would require. v.s. having n spearate x sized pools plus whatever work predivision overhead and/or synchronization overhead and/or lock semantic overhead.

I could be, and likely am, wrong; please correct me me if I am. I don't see any clear indication in the SLI wikipedia article and I'm not motivated enough to dig much deeper than that.

I do have lots of netapp gear and access to the now.netapp.com site. The entirity of the "zfs support" that netapp provides on their site is a single document from 2007 which is basically a reformatted zfs whitepaper showing that you can zfs format iscsi luns exported from a netapp... There isn't even a single line of netapp specific information in the entire document except for the format command output on page 5 has "NETAPP-LUN-0.2-8.01GB" as the friendly name for the disk...
As for your claim that netapp is more than a SAN/NAS, I'll agree there is a bit more in the way of features, but not much. I've yet to see a netapp used for much more than CIFS/NFS/ISCSI and maybe some light http/ftp work. Clustering, failover, remote mirroring, etc are neat but they are essentially just enterprise frosting on top of the basic nas/san functionality.

Also, being included in the S&P500 means that the increase in demand created by the associated index fund inclusion will (or should in theory) increase the per share value which has the resultant effect of increasing the over all value of the company as represented as the market capitalization. Larger market caps allow for much more leverage when negotiating financing on large business deals; not only by giving a greater perceived value but also by providing for more favorable rates on direct equity exchange deals.

P.S. I am not an economist and what I've posted above may be completely wrong... I'm working from very old memories of a 100 level econ course I took a long long long time ago.

Are you pot high? In what way does NetApp support ZFS? ZFS is not a NAS protocol... ZFS on SAN luns isn't a feature that needs to be explicitly supported and is the only way I can think you'd even sort of have a NA filer with ZFS on it. Also the continuing litigation by NetApp with regards to ZFS's purported infringement on NA's WAFL file system would be a pretty good reason to not believe that "Netapp [supports] ZFS".

If I missing something exceedingly obvious please reply...

The weight difference only matters for acceleration. Top speed is purely a function of max rpm, gear train reduction, aerodynamics (coefficient of drag and frontal area) and road/tire traction. Early top speed attempts with the SSC Aero hit a traction limitation near 200MPH where increased RPM only resulted in increased tire slip.

This is actually the explanation which I've read/heard is the one that Alanis Morisette herself offers with regards to the apparent incongruity between the lyrics and the title. As to whether or not she developed that response before or after writing the song is anyone's guess.

A 1960 250gt California Spyder sold for exactly that price less than 3 weeks ago... I'm just saying....

yup! Sun's openflash initiative is exactly this.

Lack of 48-bit LBA support -- couldn't stick a drive larger than 137 gig on it, which in this day and age, just doesn't quite cut it for a desktop.

You could still do this with linux though, if its an option

Not if it's a BIOS limitation.

Linux hasn't depended on the bios for handling drive geometry for ages... Sometime before the 2.2 kernel iirc.