They address this directly under the section entitled "Open-Source, not Open-Contribution":
SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons.
In other words, the reasoning is that since the code is released to the public domain, they want to ensure they can continue doing so without encumbering or confusing future releases with tainted contributions. Quite admirable.
It's pretty normal for open source projects to refuse contributions from anyone who hasn't signed a CLA or something similar. The alternative is a legal nightmare.
Just to be clear: We do not have any support contracts with the
US military, nor any other US government agency, nor any other
government entity, either inside or outside the US. Not that
we would turn down such work if it were available, it is just
that is has never come up.
Until I read the transcript, just now, I had confused SQLite's origins (a General Dynamics contract with the US Navy) with its through-2050 support contract, which, it turns out, is with Airbus.
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.
Well, it's been popular for 20 years, so that sounds fairly sustainable to me. A lot of projects with many more contributors have come and gone in that time period.
Either way, that doesn't make it "closed source" like you said in the other comment.
> There are 3 people on the planet who can make changes to it
Anyone on the planet can make changes to it and distribute those changes. The only thing those 3 can do that the rest of us cannot is get their changes into the copies distributed at sqlite.org.
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 feel like there is an implicit assumption in the article that people without a college degree won't want to switch jobs as often because they have less upward mobility as a whole.
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.
It seems like you have the perception that top talent is easy to hire. In my experience that hasn't been true at big or small companies, and if a candidate is exceptional companies will go the extra mile to get them. And if we're talking about early stage startups the power dynamic is totally reversed - the senior candidate actually has a ton of negotiating power because a startup can't compete on salary with FAANG companies, and good candidates know it.
Good senior people are selective and want to know a lot about the companies they might be joining. If they didn't ask perceptive questions I'd think it was a red flag.
I mean seriously, a startup is trying to hire a senior engineer, is offering less base salary than Google, stock with an average value of nothing and they don't even want to answer the hard questions? How would they ever hire anyone good?
The only people I'd give a pass on not knowing asking good questions in an interview are interns or new grads.
Exactly this. An employee who thinks he won't get hired, if he asks questions very relevant for him, is probably a bad hire in the first place.
And for the top talent employee the startup needs, not answering the questions is a huge red flag. If you are good, you can select between so many options and most of them pay better than a startup.
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.
Although the US has always fantasised about its military having a much better GPS than everybody else, and it seems technically to be in a position to arrange this, the reality is always that a $5 civilian device is available in every store and the $8000 military device is back-ordered and won't be in stock until after the war is won, so you use the civilian device even though it's theoretically worse.
"Selective Availability" was the first incarnation of this pipe dream. Civilian GPS would be deliberately corrupted by up to 100 metres and the correct offset would be transmitted separately to authorised military devices. But, see above, in practice when the US military needed GPS it found civilian devices were available while accurate military ones were not, so it reduces the induced error to zero and bought civilian kit for the Gulf War.
The M-code won't be deployed until 2022 (probably later, these things always get delayed). That's when those Block IIIA birds "go live" even though some will be in orbit for years before that.
Jamming the M-code is not really harder than jamming other codes, this is a broadcast radio signal you can easily transmit a more powerful signal yourself. The Block IIIA birds have an extra transmitter so they can increase power... but they still can't drown out even a relatively disposable local jammer.
Spoof genuinely is harder with an extra code... and this is the supposed benefit with owning any of the GNSS systems, you can keep a secret shared key that makes your system spoof proof until bad guys learn the key. But again, in practice when war breaks out you turn out not to have thousands of expensive military-only devices with the shared secret, so you rely on the civilian stuff anyway.
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.
The problem with saying "kubectl is the new ssh" is that it is simply not true in my opinion. Something more akin to "kubectl is to controlling a cluster as ssh is to controlling a server" would be more accurate I think. The point the OP makes about "Most Developers Don’t Have Google-Scale Problems" is true, I don't think you should use Kubernetes if your app consists of just a website and a database. But do people working on such (relatively simple) apps really consider using Kubernetes?
IMO, only if you're working on like 100+ of them. If you just maintain a website using a traditional LAMP/LEMP stack, Rails, Node.js, or something like that it still makes more sense (unless you want to be 'trendy') to stick to primitives or use more managed hosting.
But if you're maintaining a fleet of independent sites, Kubernetes' scheduling can make sense, despite the inherent complexity (TBH, you're going to have a similar level of complexity managing the same kind of scale with any other tool).
If you're an app developer you shouldn't need kubectl. AppOps should be as easy as Heroku but based on Kubernetes so you have a choice of providers and a graduation path of you need more customization. With GitLab Auto DevOps we tried to provide exactly this. It will go GA June 22. It does more then just building deployment and auto scaling, it runs your unit tests, advises if your quality improved or not, and runs four security tests. All that with a git push.
Depends on the person, team, and company. I've yet to see a company do local offices and remote work successfully at the same time. While there are plenty of examples of remote first companies having success. Seems like a communication issue.
I work for a SaaS company that started with an office in Indianapolis. We still have that office where many of our people work. However, a large portion of us work remotely. We are spread across Europe, North America, and South America.
We've been growing like crazy and things have been going well. The important thing is to make an effort to level the playing field between remote and local workers. It also helps that parts of our leadership team are also remote.
I believe success with remote work requires having the right kind of company culture. Everyone has to be aware of the pitfalls of remote work and have the tools, knowledge, and gumption to avoid them.
Some people end up not being able to swing it and others thrive. The biggest advantage we have had is being able to hire from a much larger talent pool.
Thank you for highlighting this is a such a common mistake. I hope developers of all skill levels look at this and realize it how easy it is to make this mistake and learn from it.
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.