's/always/currently/g'

Larabee my have failed. But MIC survives. If demand exists (big IF), I can imagine in the not so distant future, a startup discrete graphics card company, or Intel itself, bringing a 96 to 128 core MIC type graphics card to market, with wholly open source drivers. The performance wouldn't be nearly as good as an integrated GPU from AMD/nVidia, but it would be 'good enough' for OpenGL Linux applications, and anyone could work on the driver code. If the board design incorporated hardware support for something like either 3Dfx' original scan line interleaving, or nVidia's Scalable Link Interface, in a 2 or 4-way setup, the performance *could* be pretty phenominal, and open souce. I'd think 512 MIC cores with a good scalable driver would yield impressive 3D performance indeed.

For many it has nothing to do with money, but usability. Post WinXP, Microsoft has gone out of their way to break the UI functionality that is actually good and works. They spent hundreds of milllions of dollars researching and designing the Start Menu for Windows 95. Then NT and W2K got the same interface, and Windows XP has an option to re-enable it. It is intuitive, worked well, and everyone became accustomed to it. Then, in Microsoft fashion, they changed it simply to make it different. The reason? People won't pay for an upgrade if they feel they're not getting something for their money. How do you convey this better than chainging the UI function that people use more than any other?

In the US (and many countries) the clutch is on the left, the brake in the center, the gas pedal on the right, and the tranny shifter on right. For automatic trannies the clutch is deleted. This layout hasn't changed since the 1920s. It works well and is universally understood.

Like the driving conrols in automobiles, the UI "program menu" is something that should never need to be fundamentally changed. All changes to it since W2K have been detrimental, not beneficial. They have been made for profit reasons, not usability reasons. Microsoft Windows is a utilitarian tool, just like an automobile. What if screw manufacturers suddenly one day switched to counter clockwise threads when screws have been clockwise for over a century? Wall clocks? How about changing the road system overnight so we now drive on the left instead of the right?

For those who will inevitably, ignorantly, reply that "technology must more forward and that requires change", you miss the salient point that change is only progress when it makes something better, more usable, more intuitive. None of Microsoft's "Start Menu" changes since W2K have done so. They're done the opposite.

You're failing to recognize a key characteristic of EMC/NetApp arrays: persistent cache. SAN heads that have 8GB to 512GB of persistent cache that acks to fsync can certainly hide much of the RMW latency from transactional applications, and to a degree, the long rebuild times of their 4-8 drive parity array building blocks. EMC and NetApp arrays have massive quantities of such cache. As do the likes of the other SAN heavy hitters, IBM, SGI, HP, Oracle, etc.

Do note however that many organizations using the enterprise SAN heads with large parity RAID pools for generic bulk storage do often create separate RAID10 arrays within the unit for their high transaction rate applications, i.e. POS/CRM/BI databases, mail spools and mailboxes, etc.

And when you come down out of the stratosphere to the midrange SAN heads and then HBA RAID controllers, your persistent cache size is typically 4GB for SAN heads and 512MB for HBAs. With these systems a parity rebuild significantly degrades application performance, and during normal operation with a heavy random IOPS transactional workload RMW latency will as well. And with software RAID you don't have any persistent cache, RMW is constant, and rebuilds bog the entire system down. RAID10 or striped/concatenated mirror pairs, depending on the workload, are a much better option for these 3 cases.

It absolutely will grow, but it won't entirely displace rust. And yes, SSD latency/bandwidth do eliminate most of the performance problems with parity RAID on rust. Though the current crop of controller silicon isn't fast enough to fully take advantage of SSDs. Take your big EMC and NetApp for example. If one were to allow the controller to use up to 100% of its resources to rebuild a RAID6 array of 8 SSDs for the fastest possible rebuild time, the operation would eat 100% of the controller's cycles and other IO would suffer. With an 8 disk RAID6 rust array, it would have sufficient excess capacity to service other IO in a timely manner. To fully take advantage of SSDs in RAID, we need much faster silicon. Almost any number of certified SSDs in RAID5/6 will saturate the dual core ASIC in LSI's top RAID HBA as its parity engine can't keep up with the IO rate.

Hardware RAID has many advantages. Persistent cache, while important to performance, is but one. Far better management infrastructure is another. Many RAID vendors offer a single web management console which can control all RAID devices across a network from a single console. Try that with mdadm. Then you have superior alerting and monitoring, etc. Most RAID vendors have had excellent easy to setup/use snmp capability for over a decade. mdadm is still lacking here as is the inbuilt Microsoft RAID (does anyone actually use it?).

All hardware comes with firmware, even the SATA controller and NIC on your consumer mobo, and everyone has bugs to fix on occasion, including software RAID. This is why a good administrator reads release notes. Also note that most hardware RAID controller (PCIe card) vendors have been moving to the SNIA on disk layout metadata standards. That said, you won't find me swapping out an LSI RAID with an Adaptec, or with software RAID any time soon, simply because they all use the same metadata format and thus it should "just work". That's just not smart due to all other kinds of issues.

Spoken as I'd expect from an individual with no real hardware RAID experience/knowledge. Parity work is a tiny fraction of the operations peformed by a RAID ASIC. And in fact most enterprises don't even use parity RAID due to the huge performance penalty of RMW and the unacceptable rebuild times of parity arrays. The bulk of the work done by a RAID ASIC today is IO request processing and cache management. So no, it doesn't matter on what chip XOR calculation are performed, because those with real workloads aren't using parity RAID. If you're using Linux mdraid your parity calculations are limited to a single core per array, so if one must use parity RAID they're likely better off with a good dual core RAID card.

You really need to educate yourself. Oracle sells hardware SAN RAID arrays. ZFS doesn't have direct disk access with these.
http://www.oracle.com/us/products/servers-storage/storage/san/pillar/pillar-axiom-600/features/index.html

A UPS is not a substitute for persistent RAID cache. Persistent cache saves you from kernel panics and other crash scenarios that could corrupt your filesystem journal and/or filesystem proper, as well as saves you from power outage. A UPS only saves you from power outage.

Stop regurgitating the misinformation you read on the Wikipedia RAID page. Expend some effort and do your own research. Just about everything you've stated here is incorrect. In fact, don't do any research. Just simply keep quiet since you obviously don't use RAID and have no experience with it.

Those educated in enterprise storage assume it doesn't matter. This is a non issue with "enterprise" drives. Those willing to pay for them are attaching them to "enterprise" RAID controllers with [F/B]BWC. These controllers, whether PCIe or in a SAN head, disable the drives' NCQ/TCQ and onboard caches. The BBWC does write ordering negating NCQ/TCQ, and ensures resiliency which onboard drive caches cannot.

You must redesign your workflow. At this point you're attempting to re-engineer a flawed workflow system. Cut your losses and start over, doing this in a way known universally to work.

The first place to start is to take a large blunt object and hit the idiot over the head who decided he needed 500GB/day per "sensor" of environmental data for "undeveloped land". Oil/gas company seismic surveys of potential oil fileds don't even capture this much data, and they survey hundreds of square miles at a pop, with multiple billions of dollars potentially on the line.

Second, as others mentioned, do not try to mount and directly share the field node disks. Create a batch copy system and pull everything off the sensor node drives onto a RAID array on the server. This setup is still light years away from an optimal field data collection system. What you *should* do is:

Build a centralized field "office". I.e. a cheap plywood building relatively weather proof. Acquire a ruggedized rack server vertified for outdoor field use and a half rack cabinet on wheels. Dozens of companies sell such gear. Install a wireless router that can accept an external high gain antenna. Build a rigid square box antenna mount with 2x4s on the roof of the structure, about 6ft tall. Assuming the roof of the structure is 8ft high this gives an antenna height of 14 feet, which should be plenty if the ground you're surveying is relatively flat and you locate the building relatively close to the center of the sensor field. Connect the remote nodes securely to the AP. Create a share on the server and write all data in real time from the nodes to the server. You'll power the rack with a small gas generator sitting outside the shed, with a fuel tank large enough to run for 48 hours. This allows you to keep collecting data in the event weather etc causes you to miss a cycle.

If the data needs to be analyzed on a 24 hour cycle, you will build two identical server cabinets. Instead of collecting drives from all the nodes, you simply drive your van out, power down, disconnect a few cables, roll the cabinet out, roll the sister cabinet in, connect cables, power on, check for proper function, refill the gas tank in the generator, roll the retrieved cabinet onto the van, and go. Return to base, wheel the cabinet into the office, jack into the network, connect to the share, analyze.

THIS is how field data collection and analysis is done properly for most scenarios.

You must be referring strictly to their inbound spam filters. My MX SMTP logs suggest the rate of spam slipping past their outbound filters is a couple orders of magnitude higher.

Don't forget LCD and plasma 720p HDTVs. Over the past 5-6 years there have been over 100 million of these units sold worldwide with a native panel res of 1366x768, in the 27-42" range. I'm sure some are running Win7 and seeing media center duty today. These TVs were $900-1200 USD in 2006. People are more likely to move them to the bedroom/basement when they buy the new 50"+ 1080p model for the living room. I've even heard of some guys using the 32" models for their desktop monitor.

"marked difference" from a legal perspective or your personal moral perspective? I assume you mean moral as there is no legal distinction in most, if not all, states, WRT species covered in the state game code. For instance, prairie dog hunting in a number of Western states is legal and is a purely sporting endeavor. There is typically no limit on the number one can kill per day or per month. Nobody eats prairie dog. It tastes like shit and there's not enough meat on em to make half a sandwidh anyway. They are classified as a varmint, or pest species, because the tunnel complexes they dig often cause soil erosion problems. So farmers/land owners have an ecological reason to trim their population. Everyone else kills them purely for sport with long range rifles.

Coyotes have become a problem in multiple midwestern states due to dramatically increased populations in recent years. They used to be taken for their pelts, but prices bottomed out a number of years ago. People quit hunting them as their was no monetary gain. Nobody ate coyote, ever. They were either shot for their petls or for sport, or both. Since the pelts are worthless today, anyone shooting them is doing it mostly for sport. One other motivation is that because their populations are so high today, they are routinely killing house pets, mostly cats and micro dogs, on farms and in rural towns. My own grey tabby cat, whom I'd had for 14 years, was taken by a coyote on Oct 27, 2011. I had motivation to start killing coyotes South of town, but local law enforcement had already taken up the task. That doesn't preclude licensed hunters from still killing coyotes outside the city limits and some certainly do.

My point here is that taking game for reasons other than meat is often just as 'moral', if not more. And since everyone has a different moral compass, or should I say, everyone's moral compass points in a slightly different direction, we have laws that dictate who can shoot what animials and under what circumstances. If you have a problem with the game laws in a particular state, I suggest you start a campaign to change such laws instead of complaining on Slashdot about someone else's moral compass pointing a different direction than your own. Taking such a stance here is about as productive as pissing in the wind.

Balthorium-G.

Why wait? Intsall one of these at each house, with a relatively clear line of sight between them, align them, and you're all set, and for less than $200:
http://www.newegg.com/Product/Product.aspx?Item=N82E16833997181

11-54Mb/s betweern them which should be plenty of B/W for your use case. For distances up to a few miles the internal antenna are fine. Configure both units for ethernet bridge mode and configure MAC filtering to keep others from abusing the bridge. I'll leave the rest to you, as surely you can figure it out, being a /. member.

Apparenly you've read some of my list posts. Yes, FDC Servers has a bad rep for hosting snowshoe spammers. In all fairness to FDC, all providers of ultra cheap VPS/hosting/cloud/colo servers are snowshoe spammer magnets preceisely because of the low cost. And as a consequence of low margins, they most often can't afford to staff real abuse departments. Which is why many mail operators simply SMTP ban the entire address space of these outfits, often at the edge firewall to keep the traffic off the MTAs.

It simply became too time consuming, long ago, to play whack-a-mole in an attempt to let though the few legit senders on these networks. Other providers in the same general category: Steadfast, iWeb, Hurricane Electric, Turnkey Internet, Sharktech, Softlayer, Reliance Globalcom, Syptec, ColoGuys, Colo4, Singlehop, Liquidweb, AccelerateBiz, Limestone, Staminus, Layered Tech, Eonix, 1&1 Internet, Hostnoc, VPLS, Digital Connexxions, Corporate Colocation, Versaweb, FortressITX, Suavemente. Those are just ones on my radar, and I run a pretty small receiving operation.

If one desires to rent a server/VPS with the intent to send email from it, I'd steer clear of the above networks. Rackspace would be a better choice as their abuse dept seems to do a good job of keeping the house fairly clean and has a much better rep WRT spam emission. Softlayer and Limestone actually have good abuse desk managers. I see them booting snowshoe spammers off their networks almost daily. But it seems they simply can't keep up with the rate at which their sales forces are signing up new snowshoe spammers--poor or non-existent vetting process.

Everyone wants cheap service, especially snowshoe spammers. Keep in mind that hosting cost has a direct impact on their bottom line, whereas this is less important for a guy who just needs one server and one IP for a personal setup. Thus, if you want to separate yourself from spammers, go to a provider that charges twice the average cheapo rate on the market. Odds are you won't have spammers in your midst, and thus you won't have problems with your mail being rejected.

Correct. But enabling Address Windowing Extensions (AWE) atop PAE allows applications built with AWE support to access up to 64GB of RAM on 32 bit Windows 2003/2008 Enterprise or Datacenter systems. However, given the cost of these server editions of Windows, it is obviously much smarter to simply do the builds on 64bit Windows XP/Vista/7 selecting a 32bit Windows target.

So I guess those oil pumps on said land were there before we transformed everything? Bullocks. Even if that's the real concern, there is plenty of pristine prairie in the national parks on the Eastern slope of the Rockies. The lazy American Indian tribal elders simply want to be paid a high rent for the land the wind turbines sit on, period. Do a little Googling or watch PBS to learn about reservations, the corruption, the fat pockets of the elders, the shacks that the average "tribesmen" live in, the total lack of productivity, the 70%+ unemployment rate, rampant alcoholism encouraged by the "haves" to keep the "have nots" sedated and agreeable, etc. There aren't enough population centers nearby to make a casino profitable in those lands, unlike other reservations in the region, so the "free income" sources for these tribes are much more limited. They want a payday, pure and simple.

We have 3 arrays of wind turbines in Atchison County, Missouri, a 72, a 24, and a 4. The first two feed grids and the 4 turbine site powers the city or Rock Port. There was a big effort here years ago to get these wind farms, for a few reasons:

1. JOBS--including initial construction (hundreds) and maintenance. Less than two dozen long term jobs were created but they pay very well in this rural area with a population of about 5,000 and a workforce of around 1,500. Most of the total population is retired/elderly.
2. Local economy boost during the 2+ year construction--hotel rooms for crews, restaurants, etc.
3. Property tax revenue on the rigs which is in the multiple thousands per rig per year even after the "tax breaks" used to draw the operators
4. Land stipend (rent) to the farmers who gave easement, $5,000/year per turbine--some farmers have 20 units on their land--$100k/year

Note that the Indian elder did not mention JOBS at all, only easement rent, and curiously, nothing about tax revenue. Politicians are always about jobs for their constituents, and these elders are politicians by definition. They don't want jobs for their people, simply a fat payday, just like they currently have with the oil. At this point in the game, the Indians are simply attempting to generate sympathy in the press to drive up the payment amount down the road when they sign the papers.

You might have the bullet diameter correct, but your velocity figure is way the fuck high, showing you're not a gun guy, and should thus leave responses such as this to gun guys such as myself. :)

Many of these SEAL operators would have likely been carrying the M4A1 carbine. Muzzle velocity w/ M855/A1 ball, most likely what they loaded out with, is 2900 fps or less from the 14.5" barrel of this weapon, depending on altitude, temperature, humidity, etc. You're 600 fps high in this case.

Given that SEAL Team 6 has been dedicated to counter-terrorism operations since the unit was formed, and is often engaged in Close Quarters Battle, such as the bin Laden raid, some operators were likely carrying the MP5N or MP5SD submachine gun instead of the M4A1 carbine. Muzzle velocity of these two MP5 variants is 1300 fps. If one of these meat eaters popped bin Laden the bullet diameter would have been 9mm, and your velocity would have been high by an whopping 2200 fps, just shy of triple the actual projectile velocity.