That didn't age well...
2,051 karma · joined November 2, 2009
That didn't age well...
If he made a statement that he changed his mind, I'd be happy to see it.
I'm all for freedom of speech, but I don't see how people can defend these kind of opinions he's advocating.
* It used outdated NEDC tests instead of WLTP numbers. (Diesel) car makers are known to have cheated NEDC tests for decades, using corrected WLTP numbers changes the whole story.
* It exaggerated the CO2 emissions for production of batteries, Tesla's Gigafactory emits 2.6x less CO2 per kWh than assumed.
* It assumed a battery lifespan of just 150k km. Tesla's rated battery lifespan is over 2M km, so taking 300k as very conservative number changes the calculation significantly.
* It assumed an energy mix of today, instead of an increasing share of renewable energy in the future.
Using corrected data, the Tesla emits actually 63% less CO2 instead of 11-28% more.
If you want to see how things work, start a small ad campaign yourself of FB. It's all about ROI, attribution, cost per action, super detailed targeting, etc. It's the opposite of "throwing money at it hoping that it'll work", unlike offline advertising or even traditional display ads.
1. https://itunes.apple.com/us/app/telegram-x/id898228810?mt=8 2. https://play.google.com/store/apps/details?id=org.thunderdog...
Our production Cloud SQL started throwing errors that we could not write anything to the database. We have Gold support, so quickly created a ticket. While there was a quick reply, it took a total of 21+ hours of downtime to get the issue fixed. During the downtime, there is nothing you can do to speed this up - you're waiting helplessly. Because Cloud SQL is a hosted service, you can not connect to a shell or access any filesystem data directly - there is nothing you can do, other than wait for the Google engineers to resolve the problem.
When the Cloud SQL instance was up&running again, support confirmed that there is nothing you can do to prevent a filesystem crash, it "just happens". The workaround they offered is to have a failover set up, so it can take over in case of downtime. The worst part is that GCS refused to offer credit, as according to their SLA this is not considered downtime. The SLA [1] states: "with respect to Google Cloud SQL Second Generation: all connection requests to a Multi-zone Instance fail" - so as long as the SQL instance accepts incoming connections, there is no downtime. Your data can get lost, your database can be unusable, your whole system might be down: according to Google, this is no downtime.
TL;DR: make sure to check the SLA before moving critical stuff to GCS.