jread

I've been standing for 5 years and love it - no back pains and feel much better physically and mentally at the end of a day compared to sitting.

The biggest issue for me is foot fatigue. I now use 2 anti-fatigue mats - a rubber lower mat (Genuine Joe Anti Fatigue Mat), and a foam upper (Imprint Cumulus9 Kitchen Mat Nantucket Series). Without these there is no way I could handle more than 6 hours. However, even with them, I still have sore feet after 10-12 hours (8 hours is ok). Another useful component of a standing desk is a foot stool to periodically shift weight around.

Desk Pics: https://photos.app.goo.gl/rQBWwBQx97liILOn1 https://photos.app.goo.gl/CVrK8p1ukau5kLiw2

My point is I don't think Ford is even remotely taking electric vehicles seriously. With a little better engineering the Focus electric could have been a decent $35k electric car.

It was a 2 year lease, $239/mo - and California gave a $2500 rebate also, so cost and risk were low. I wanted to try electric and couldn't afford a Tesla at the time.

Aside from batteries, supercharger network, and any true desire to actually build nice electric cars. I drove an electric Ford Focus for 2 years, and it was an absolute terrible afterthought of an electric car. It was downright dangerous on wet surfaces with front wheel drive and batteries in the rear, not to mention the horrendous user experience that is Ford Sync. I drive a Tesla now and couldn't be happier.

GCE is a great platform with many competitive advantages including networking, flexible configurations and sustained use discounting. However, I'd argue that using different data points and comparison criteria the opposite hypothesis could be made in favor of EC2 - e.g. burst instance/storage, spot and reserve pricing, local SSD and magnetic storage, and others.

Now impacting multiple regions including both US East and US West with very query failure ratios - 50-70%

Seems to be impacting POPs in US East most severly. We use Ripe Atlas to assess the impact of DNS outages, and in the past hour have measured about 50-60% recursive query failure from a few hundred probes in that region: https://cloudharmony.com/status-for-dyn

There are 3 cases where rolling through or jump starting at a red light makes sense, and is sometimes safer in my opinion. The first is a t-intersection where the bike lane runs through the non-traffic side - its absolutely safe to run these if you've verified nobody is in the crosswalk. The second is fast moving roads with no or shared bike lanes. In this case I find safely rolling through allows me to get ahead of traffic and up to speed before cars start flying by. I feel this is safer than impeding traffic as you clip in and more slowly get up to speed. Finally, red lights with pressure sensors and no upcoming cars to trigger them. Unless you want to sit there all day I think it's ok to roll through these.

I've added a disclaimer. We do not profit in any way from these incidents.

Our outages were triggered as a result of ICMP timeouts.

Is there a reason for the downvotes?

I founded CloudHarmony and now work for Garter which acquired CloudHarmony in 2015.

According to network checks we have running against VMs in each GCE region, this event resulted in about 1.6 hours of concurrent ICMP timeouts for every region (except us-west1 for only 10 minutes). We use Panopta for monitoring which verifies outages from multiple external network paths. When outages trigger we also use Ripe Atlas to confirm them using 100s of last mile network paths of which 85-95% resulted in timeouts. This is the second global GCE networking outage this year. These outages are particularly problematic because even multi-region load balancing will not avert downtime.

https://cloudharmony.com/status-for-google

Prior global outage - April 11: https://status.cloud.google.com/incident/compute/16007

Disclaimer: I am the founder of CloudHarmony Edit: Outages triggered due to ICMP timeouts

FYI - we verified outages from hundreds of last mile routes using Ripe Atlas probes with failure rates in the range of 86-96%.

I think partially due to the timing - 12-2AM PT vs 6-7PM on April 11. Google hasn't provided specifics - but our VMs in every region were 100% inaccessible during that period.

I think concurrent is better in this context because the outage periods overlapped but were not synchronized.

Word of caution - we've observed 2 global (all regions down concurrently) networking outages on GCE this year. 18 minutes on April 11 and 1.5-1.7 hours last night (except for us-west1 - down only 10 minutes):

https://status.cloud.google.com/incident/compute/16015 https://status.cloud.google.com/incident/compute/16007 https://cloudharmony.com/status-for-google

According to my availability checks - GCE experienced about 1.6 hours of downtime last night in every region except the newest - us-west1 which was only down for 10 minutes:

https://cloudharmony.com/status-for-google

This is the second global GCE outage this year:

https://status.cloud.google.com/incident/compute/16007

The stats are simply to provide some context. I agree criticism is centered around communication/PR, but also seems to imply the outage was of the same magnitude or worse than GCE's global outage, which is inaccurate. Per HA best practices, multi-region load balancing or failover would have adverted downtime during this event, whereas it would not have during the global GCE outage. Had this been a global outage, I think the postmortem and customer outreach would have been much better.

2 hours aligns with the postmortem, 12 hours does not. The monitoring is based on a sampling of instances running in each service and region. Outages are verified from multiple network paths. While not comprehensive, over the years this has been generally accurate because most outage events have been network or power related, thus impacting most or all instances in the affected data center. There have been some isolated hardware failures, but they are rare.

I independently monitor availability of 150 public cloud services and only observed 1.73 hours downtime for this event. This is the first EC2 outage I've observed in any region for over 6 months. According to my stats, in 2015 EC2 was highly available with 6 of 9 regions (including every US and EU region) having no outages, and total average service availability of 99.998% (78% of downtime in sa-east-1). I haven't observed a single outage in us-west-2 or eu-west-1 in nearly 3 years. This compared to 16-33 minutes of downtime in every region for GCE in 2015, and total average availability of 99.995%. Additionally, since 2013 I've never observed a global EC2 outage like the 4/11/2016 GCE event.

https://cloudharmony.com/status-for-aws

I think that understates it a bit. AWS Lambda is backed by a fleet of servers managed around the clock by one of the largest and most experienced IT organizations in the world, and API Gateway is fronted and cached by Amazon CloudFront's global network of servers.

Not the full Akamai network - only 219 edge locations out of many thousands on Akamai's full network:

http://go.rackspace.com/cdn.html?cm_mmc=PPC_NonBrand-_-US_Cl...

Amazon.com uses UltraDNS and Dyn

Although GCP has some distinguishing technical features like live migrations, based on my own independent availability monitoring, it hasn't been any more reliable than other cloud services including Azure and DigitalOcean. In fact, over the past year, EC2 has been much more reliable than GCE. The most common problems I've observed are network blips that may or may not get reported on the GCP status page.

https://cloudharmony.com/status-1year-for-google https://cloudharmony.com/status-1year-for-aws https://cloudharmony.com/status-1year-for-azure https://cloudharmony.com/status-1year-for-digitalocean

The Nest Wave feature has been disabled since April 2014 https://nest.com/support/article/Nest-Protect-Safety

I can attest to similar feelings during multiple middle of the night false alarms with dog barking and kids crying. I've followed online support articles including regular dusting and all units are hard wired. I've spoken with support on multiple occasions and exchanged 3 of 5 units with Nest. The units have improved over time with software updates, but continue to be problematic. During one recent false alarm we were not home and the neighbors called the fire department who had to break in to verify there was no fire and disable the alarm. I contacted Nest support after that incident and they were unable to determine the cause of the alarm. We never had a false alarm with the previous dumb detectors.

And 24 hour run limit

He may be comparing Google's total data center capacity (search, cloud, etc.) to AWS. I do monthly scraping to track cloud marketshare for Alexa 10k and Fortune 500. From that analysis, EC2 is at 12-14% marketshare compared to < 1% for GCE and 1-2% for Azure's VM service. http://blog.cloudharmony.com/2015/03/compute-marketshare-ale...

All our status VMs are unreachable: https://cloudharmony.com/status-for-google