I liked the MacBook Air form factor, but not the OS so I blew away MacOS completely and replaced it with Fedora 17. Overall it's been great, it "just works." Gnome 3 works well on it and fully integrates with the brightness and volume buttons without issue. I did however install a few Gnome extensions like Axe Menu, Alternate Tab, and Task bar, now it's not unlike any desktop I've grown used to. Libvert also works well on it allowing me to build test servers when I need. Overall it's a 95+% solution for me.

>> But if you COULD have a doctor there, without messing with Skype or a webcam, would you think that's a bad idea?

> The doctor is at the hospital, treating the other patients who may have life-threatening injuries. You're suggesting the doctor step away from those duties to help the EMTs perform... basic triage?

As a former EMT I would also point out there is a reason a doctor is in a hospital, not an ambulance. Doctors are very well trained at what they do, and they are used to having many tools at their hands in the hospital, but in the field none of those tools exist. I have said this before to many people, those who work in a hospital can be some of the worst people to provide assistance in the field as a citizen responder. This is a paradox, the best trained person is the worst person to provide assistance at a car wreck they just witnessed? But it's true. EMTs focus on the basics to get the patient to advanced care quickly (Platinum 10, golden hour). In addition doctors and nurses are not used to thinking about things like scene safety and how they could become another victim. Lastly let's say you had the hospital in a box and you could move the patient into this immediately after the accident etc, the first thing they will be doing is stabilizing, after that is done *then* they consider diagnosis and treatment.

CHAOS = Chief Has Arrived On Scene.

Just in case our "Upside down" compatriots in Australia are confused about an Ox-Bow lake, you would know them as a Billabong, yes body of water that the Swagman boiled his billy by and ultimately jumped into is real...

And to bring the comparison full circle, the Big Mac Index from January 2012 showed Latvia to be -30% parity. Meaning if you were to adjust the price to US Dollars it would cost an equivalent of about US$15-16 in the US.

The index can be found here:
http://www.economist.com/blogs/graphicdetail/2012/01/daily-chart-3

Consider this, if a CEO takes a $1 pay package and receives only company stock as their benefits package that means the company has to do well for them to make money. In addition *you* are free to invest in these companies and "freeload" on their incentive package and earn some income as well.

You might need to heat up the butter as it looks like it may cool and solidify before eating...

Tell that to Susanna Hupp after the Luby's shooting. She watched a gunman shoot both of her parents, while her gun was lawfully elsewhere, it was illegal at the time to conceal carry in Texas.

Statistics show taking guns away causes an increase in violent crime... See Australia and England
Statistics show that allowing for more lawful firearm posession (concealed carry) tends to reduce violent crime... See Florida, Texas etc.

The bottom line really comes down to this... Do you want to have a 100% guarantee that a criminal can shoot you with impunity, or a chance to protect your life... Tell that to Susanna Hupp after the Luby's shooting.

Who will they blame when gun violence goes up?

Raid is toast. I dont care WHAT raid you are running, none of them can withstand a loss of 50% of the drives.

Really? I used to do that as a routine acceptance test for clusters. The only times it failed for real was when we'd screwed up something.

For that to work, you have to rigorously separate RAID mirrors into their own trays so that a whole tray failure (or cable, as you said) only takes one mirror down. For something like 10, 50, 60 you just make sure all of one side is on one array and all of the other on another (or if you have more than 2 arrays, that you separate them out into pairs with one used for one side and one for another).

Physical separation helps as well, so that you don't accidentally unplug A while starting servicing on B. That exact scenario is one of the canonical HA oopses.

Old SAN / Cluster folks believe in belt+suspenders. I.e., often, use both.

Use Software RAID 1 across a couple of LUNs (or separate controllers / drive array stacks, for non-SAN environments). Build the LUNs with internal RAID (5, 6, hot spares, figure out your rebuild times, etc.)

Also - hugely common failure is that the operators aren't properly monitoring the underlying hardware RAID drive status. You need to know immediately when a drive fails even if there's RAID6 and a couple of hot spares in the array. When I worked for a VAR on clusters, I can't count the number of times I arrived and found that they'd had 2, 3, 4 failures nobody noticed, and were one more failure away from catastrophic data loss...

There is a very slight bathtub type curve - all numbers rounded, it's about 3% AFR in the first quarter (i.e. about 0.75% failures in first quarter) and 2% for drives in the 3-12 month range (i.e. about 1.5%). If I read the statistics presentation there right 33% of first year failures look to happen in the first quarter, which is detectable but minor initial higher rate. That's dwarfed by 1-2 year AFR (about 8%) and 2-3 year AFR (about 9%), but drops slightly after that.

They presented the AFRs rather than the culminative losses in an initial cohort per quarter/year, which would be slightly clarifying, but whichever way they did the analysis it's about like that.

I have worked for an OEM who installed about 30,000 drives a year; for end users with 10,000 drive environments, built out new 1,000 HDD and 600 SSD environments in the last year. I know all about static, having had the manufacturer-level training on how not to zap.

It's not just static. Some drives come with SMART errors (or bad blocks that matter), despite $MFGR assurances. Some of the failures develop in the factory and get shipped anyways as unlikely to get worse, some develop while being packaged or shipped or unpackaged. Run SMART data collection across hundred-drive collections (or thousands or more) and you get a lot of useful and scary info.

Also, there are well documented runs of drives - specific models, time ranges, factories involved etc - which all just blew up. Also happens to chips sometimes - I've been seriously bit by bad CPUs by Sun and Intel, support chips from several vendors. Also RAM going bad.

One prototype CPU literally melted the system down, all the plastic nearby inside the casing melted and puddled on the bottom of the case, the CPU label plastic was carbonized.

While technically true, this argument does fall apart when a company such as Oracle rebrands RHEL into OEL, then goes on the offensive against RHEL/Red Hat when they don't have much of a team of developers to continue developing OEL should the hypothetical, but very unlikely, situation of Red Hat going away. In a situation such as that it's kind of like Oracle is biting the hand that feeds it.... CentOS on the other hand rebrands RHEL, but does not try to present themselves as the main proprietor of the distribution. In addition the CentOS community does try to push bug reports upstream when possible.