hharnisch

There are 3 people on the planet who can make changes to it and one person who can work on their custom made source control system. Single points of failure are not sustainable.

For all the great things about SQLite there are some concerning things around the project.

First off, even though the source code is public domain, you can't contribute since it is closed source: https://sqlite.org/copyright.html

There are 3 developers who maintain the project https://www.sqlite.org/crew.html and operate under a "code of ethics" that used to be called their "code of conduct" https://sqlite.org/codeofconduct.html

While it succeeded in getting widely adopted I have trouble believing that this is sustainable.

Having worked in Cedar Rapids there's really only 1 employer that makes up the "good job" pool - used to be called Rockwell Collins.

I'd guess there's a similar situation in most of towns on this list, which would mean living there is a huge risk unless you plan on working at the one or two companies in town for life.

I was expecting another company copying the core business logic based off the title, but it looks like things related to redirect and auth are very (very) similar.

Nearly every API is going to need solutions for these, and they all look very similar. I'd be surprised if the redirect and auth parts weren't at least in some way inspired by other APIs.

The company doesn't have to answer every question but it would be a huge red flag if the company could not answer any of them.

We often use GPS as a way to synchronize time accross distances. Even Google's data centers use GPS (and an atomic clock) for synchronization - https://www.google.com/amp/s/www.theverge.com/platform/amp/2...

GPS is such a weak signal that almost anyone transmitting ground based signals on the right frequency could easily drown out GPS - and do spoofing with a little extra research. So theoretically you could spoof near a data center and mess up a lot of data powering 1000s of applications.

On top of this civilian GPS is made to be jammed and innacurate - there's a better one the military has moved onto because of this (see the m-code section: https://en.m.wikipedia.org/wiki/GPS_Block_IIIA)

So yes, relying on an easily jammed atomic clock hurtling through space seems like a bad idea... But it's kind of the best we've got right now. At least until the cost of putting your own satellite into orbit goes down.

I switched from the native Facebook app to the web app in 2014 -- which is the last location Facebook has on me. I guess this explains why deleting the app gave me double the battery life.

I've gone to the last few KubeCons and given talks at two of them and I'd also consider myself to be more of an app developer than ops. The tone has been very much that Kubernetes is deeper in the stack than most developers want or need to be thinking about. Mantras like "kubectl is the new ssh" have become super popular. So Kubernetes ends up being the platform you build your tools developers deploy their applications with -- if you work on ops. The problem seems to be that there's not a lot of agreement on what those tools actually look like. What Kubernetes does end up doing is providing a consistent API to deploy workloads across (many, but not all) cloud providers. Over time we'll see better and better developer facing solutions built on top of Kubernetes, rather than part of Kubernetes.