The real issue is that this is more nuanced than is appropriate for one-size-fits-all advice. "Everyone should use a monorepo" isn't helpful, but neither is "everyone should not use a monorepo."
Sadly, this article falls into the same trap.
1,215 karma · joined May 19, 2008
Twitter: @obeattie
Sadly, this article falls into the same trap.
Just for interest, could you elaborate? How does the West Coast (of the US, I assume you mean) do things?
One thing I’d be interested to know more about is why it took 17 minutes to fix. While you can and always should strive to make them less likely, outages are inevitable, so how you respond is crucial. Here the outage was very obviously caused by a deployment that I’d assume was supervised by humans – why did it take 17 minutes to roll back?
Our entire backend has been built in-house using modern tech. You can read a bit more about it on our blog if you’re interested: https://monzo.com/blog/2016/09/19/building-a-modern-bank-bac...
(Context: I am the Head of Engineering at a bank.)
But surely we have oodles of data from devices like Fitbits and Apple Watches to know whether this behaviour is true for humans or not.
But that isn't what their statement says. It says the victim had his hands off the wheel for six seconds before the crash, and that he received hands-on warnings "earlier in the drive." It does not say that during those crucial six seconds he was being warned. Nor does it explain the fact the car plowed into a barrier.
Uber made sure to point out that the victim of their incident was homeless. Tesla is pointing out how the driver received unrelated cues earlier in the journey. None of this information is relevant. They’re trying to bamboozle the reader in an effort to improve their images at the expense of victims who can’t defend themselves.
I don’t understand why it is so impossible for these companies to act humbly and with a sense of dignity around all this. I don’t expect them to accept responsibility if indeed their technology was not to blame, but frankly that isn’t for them to decide. Until the authorities have done their jobs, why not show remorse, regardless of culpability, as any decent human would?
We first deployed v1.2 nearly 2 years ago, and I can say Kubernetes has made some amazing improvements in that time – in terms of functionality, usability, scalability, and stability. This release continues that trend.
We've invested a lot in it too with things like making sure our etcd clusters backing Kubernetes are really solid [2], and we've even added some of our own features to Kubernetes like allowing CPU throttling to be more configurable to get more predictable >p99 latency from our applications.
We've been through our share of production issues with it (some of which we've posted publicly about in the hope that others can learn more about operating it too [3]), but I don't think there's any way in which we could run an infrastructure as large and complex as ours with so few people without Kubernetes. It's amazing.
[1] https://monzo.com/blog/2016/09/19/building-a-modern-bank-bac...
[2] https://monzo.com/blog/2017/11/29/very-robust-etcd/
[3] https://community.monzo.com/t/resolved-current-account-payme...
> Advanced driver-assist technologies were one of the first technologies our teams explored. In 2012 we developed and tested a Level 3 system that would drive autonomously on the freeway in a single lane but would still require a driver to take over at a moment’s notice. During our internal testing, however, we found that human drivers over-trusted the technology and were not monitoring the roadway carefully enough to be able to safely take control when needed.
> As driver-assist features become more advanced, drivers are often asked to transition from passenger to driver in a matter of seconds, often in challenging or complex situations with little context of the scene ahead. The more tasks the vehicle is responsible for, the more complicated and vulnerable this moment of transition becomes.
> The Borgmaster is a monolithic component that knows the semantics of every API operation. It contains the cluster management logic such as the state machines for jobs, tasks, and machines; and it runs the Paxos-based replicated storage system used to record the master’s state.
So it sounds as though Borg includes its own storage system. As I understand, Google has a set of (very complex) libraries written in C++ that implement Paxos/Multi-Paxos[2], which they have not open sourced.
[1] https://research.google.com/pubs/pub44843.html [2] https://research.google.com/archive/paxos_made_live.html
>This panic is caused by dereferencing a nil pointer, as indicated by the first line of the output. These types of errors are much less common in Go than in other languages like C or Java thanks to Go’s idioms around error handling.
I often see assertions made like this about Go. My experience at companies which use Go as their primary development language with reasonably-sized teams (30-50 people working on hundreds/thousands of Go programs) does not agree with this. I would say nil pointer dereference errors are just as common as if they were writing code in C or Java. I don't have hard data to back this up though; perhaps you do.
Signatures have been all but obsolete for purchases in Europe for years; I can’t even remember the last time I used it here. Everything is contact or contactless EMV now, authenticated by PINs.
https://www.authy.com/phones/change/
It says they may perform "additional security checks" in the help but what are they? The wooliness of this makes me very nervous. (I don't use Authy fwiw)
"We've identified the issue as high error rates with S3 in US-EAST-1, which is also impacting applications and services dependent on S3. We are actively working on remediating the issue."